Esta é uma Tradução Autorizada de um documento do W3C. A publicação desta tradução seguiu os passos descritos na Política para Traduções Autorizadas do W3C. No caso de controvérsias a versão oficial da especificação é o documento original, inglês.
Este documento apresenta as Boas Práticas relacionadas à publicação e ao uso de dados na Web, concebidas para apoiar um ecossistema autossustentável. Dados devem ser descobertos e compreensíveis por pessoas e máquinas. Em qualquer circunstância em que os dados sejam utilizados de alguma maneira, seja pelo criador original dos dados ou por uma parte externa, tal utilização deve ser igualmente descoberta, assim como devem ser reconhecidos os esforços do publicador dos dados. Ou seja, a adoção destas Boas Práticas facilitará a interação entre publicadores e consumidores.
Estado deste Documento
Esta seção descreve o estado deste documento no momento de sua publicação. Outros documentos podem substituí-lo. Uma listagem das publicações atualizadas do W3C, assim como a última revisão deste relatório técnico, podem ser encontradas no índice dos relatórios técnicos do W3C em https://www.w3.org/TR/ (em inglês).
Este documento foi revisado pelos Membros do W3C, por desenvolvedores de softwares além de outros grupos e partes interessadas do W3C, e foi endossado pelo Diretor como uma Recomendação do W3C. É um documento estável e pode ser utilizado como material de referência e citado em outro documento. O papel do W3C ao emitir uma Recomendação é chamar atenção para a especificação e promover sua ampla implementação. Isto aperfeiçoa a funcionalidade e a interoperabilidade da Web.
As Boas Práticas abaixo descritas foram desenvolvidas com o objetivo de estimular e possibilitar a expansão da Web como um ambiente para a troca de dados. O crescimento do compartilhamento online de dados abertos por parte de governos de todo o mundo [OKFN-INDEX] [ODB], a crescente publicação online de dados de pesquisa, encorajada por organizações tais como a Research Data Alliance [RDA], a coleta, análise e publicação online de dados de mídias sociais, crowdsourcing de informações, a progressiva presença na Web de coleções importantes ao patrimônio cultural, tais como o acervo da Bibliothèque nationale de France [BNF] e o crescimento sustentado na Linked Open Data Cloud [LODC] são alguns dos exemplos desse crescimento do uso da Web para a publicação de dados.
No entanto, este crescimento não é consistente em termos de estilo e, em muitos casos, não faz pleno uso do potencial da Plataforma Aberta que é a Web para estabelecer conexões entre fatos, descobrir recursos relacionados e criar visualizações interativas.
Em termos gerais os publicadores de dados visam compartilhar dados seja de forma aberta ou por meio de acesso controlado. Por sua vez, os consumidores de dados (que também podem eles mesmos ser publicadores) querem ser capazes de encontrar, usar e relacionar os dados - especialmente se estes forem precisos, regularmente atualizados e tiverem disponibilidade garantida a qualquer momento. Isto leva a necessidade de se alcançar um entendimento comum entre os publicadores e os consumidores de dados. Sem este acordo, os esforços dos publicadores de dados podem se revelar incompatíveis com os desejos dos consumidores de dados.
A abertura e flexibilidade da Web cria novos desafios tanto para publicadores quanto para consumidores de dados, tais como representar, descrever e disponibilizar dados de maneira compreensível e fácil de encontrar. Diferentemente de bases de dados convencionais, por exemplo, em que há um único modelo de dados para representá-las e um sistema de gerenciamento de base de dados (do inglês database management system, DBMS) para controlar o acesso aos mesmos, os dados na Web permitem a existência de múltiplas formas de representação e acesso aos dados. Para maiores detalhes sobre os desafios veja a seção Desafios de Dados na Web.
Neste contexto torna-se fundamental prover diretrizes aos publicadores para que o gerenciamento de dados seja mais consistente. Tais orientações ajudam a promover a reutilização dos dados e a fortalecer a confiança nos dados entre os desenvolvedores - seja qual for a tecnologia que estes escolham - incrementando o potencial para inovações genuínas.
Entretanto, nem todos os dados devem ser compartilhados abertamente. A segurança, a sensibilidade comercial e, acima de tudo, a privacidade dos indivíduos devem ser levadas em consideração. Cabe aos publicadores de dados determinar as políticas por meio das quais os dados devem ser compartilhados - e sob quais circunstâncias. Espera-se que as políticas de compartilhamento de dados avaliem o risco de exposição e estabeleçam as medidas de segurança apropriadas para a proteção de dados sensíveis, tais como a autenticação segura e a autorização.
Dependendo das circunstâncias, informações sensíveis sobre indivíduos podem incluir nome completo, endereço residencial, endereço eletrônico, número de identificação nacional, endereço de IP, número de registro de veículo, número de carteira de motorista, rosto, impressões digitais ou de caligrafia, números de cartão de crédito, identidade digital, local de nascimento, informação genética, número de telefone, nomes de login, nome de tela, apelido, históricos de saúde, etc. Embora seja possível que o compartilhamento de algumas destas informações de forma aberta seja seguro, sobretudo em ambientes controlados, os publicadores devem ter em mente que a combinação de dados oriundos de múltiplas fontes pode permitir a identificação inadvertida de indivíduos.
Uma Boa Prática genérica para a publicação de dados na Web é o uso de padrões. Diferentes tipos de organizações especificam padrões que são particularmente dirigidos à publicação de conjuntos de dados relacionados a domínios e aplicações específicas, envolvendo comunidades de usuários interessados nestes dados. Estes padrões definem uma forma comum de comunicar informação entre os usuários destas comunidades. Por exemplo, existem dois padrões que podem ser utilizados para publicar horários de transporte público: o General Transit Feed Specification [GTFS] e o Service Interface for Real Time Information [SIRI]. Tais padrões especificam de maneira inter-relacionada, conceitos padronizados, formatos e acesso padronizados a dados. Outra Boa Prática genérica é a utilização do Unicode no trato dos caracteres e dos dados em string. O Unicode aprimora o processamento de texto multilíngue e facilita a localização de softwares.
As Boas Práticas abarcam diferentes aspectos relacionados à publicação e ao consumo de dados, tal como formatos de dados, acesso a dados, identificadores de dados e metadados. Com a intenção de delimitar o escopo e levantar as características e requisitos necessários para a elaboração de Boas Práticas para Dados na Web (do inglês Data on the Web Best Practices, DWBP), o grupo de trabalho DWBP compilou uma série de casos de uso, presentes no documento Requisitos e Casos de Uso das Boas Práticas para Dados na Web, do inglês Data on the Web Best Practices Use Cases & Requirements [DWBP-UCR], que representam cenários sobre como os dados são comumente publicados na Web e como são utilizados. Esta série de requisitos derivada dos casos de uso foi utilizada para orientar o desenvolvimento das Boas Práticas que independem do domínio e da aplicação. No entanto, elas podem ser estendidas ou complementadas por outros documentos ou padrões de Boas Práticas que tratem de contextos mais específicos. No que diz respeito aos vocabulários, por exemplo, a nota Boas Práticas para Publicação de Dados Conectados, do inglês Best Practices for Publishing Linked Data, [LD-BP] do W3C, é uma boa referência. Existem recomendações específicas para expressar licenças, outras permissões e declarações de obrigações em ODRL [ODRL-model], um conjunto de padrões relacionados a procedência [PROV-Overview] e as Boas Práticas aqui apresentadas, que foram estendidas para abarcar orientações mais específicas acerca da facilidade de descoberta, facilidade de acesso e interoperabilidade de dados espaciais e temporais da nota do W3C Boas Práticas para Dados Espaciais na Web, do inglês Spatial Data on the Web Best Practices [SDW-BP].
Mesmo que o DWBP recomende o uso de Dados Conectados, o documento também estimula boas práticas para dados na Web em outros formatos abertos, tais como o CSV. Métodos para o compartilhamento de dados tabulados, inclusive arquivos CSV, de modo a maximizar o potencial da Web para estabelecer links entre pontos de dados, são descritos no Tabular Data Primer [Tabular-Data-Primer].
Com o objetivo de estimular os publicadores de dados a adotarem o DWBP, uma série de benefícios foram identificados: compreensão, facilidade de processamento, facilidade de descoberta, reúso, confiança, capacidade de conexão, facilidade de acesso e interoperabilidade. Tais benefícios foram descritos e relacionados às Boas Práticas na seção Benefícios das Boas Práticas.
2. Público
Esta seção não é normativa.
O presente documento define as Boas Práticas dirigidas especialmente àqueles que publicam dados na Web. As Boas Práticas foram elaboradas para atender à demanda das equipes de gestão de informações, desenvolvedores, além de grupos mais amplos, tais como cientistas que estejam interessados em compartilhar e reutilizar dados na Web. Ainda que os publicadores de dados sejam o nosso público principal, encorajamos todos os envolvidos em atividades correlatas a familiarizar-se com o tema. Realizamos todos os esforços possíveis no sentido de tornar este documento legível e utilizável - mantendo a precisão e a clareza que uma especificação técnica demanda.
Espera-se que os leitores deste documento estejam familiarizados com alguns conceitos fundamentais da arquitetura Web [WEBARCH], tais como os recursos e os URIs, assim como com uma série de formatos de dados. O elemento normativo de cada Boa Prática é o resultado pretendido. Algumas implementações possíveis também são sugeridas e, quando apropriado, tais implementações recomendam a utilização de uma tecnologia específica. Um conhecimento básico de vocabulários e modelos de dados é útil para entender melhor alguns aspectos deste documento.
3. Escopo
Esta seção não é normativa.
Este documento trata somente de Boas Práticas que:
são especificamente relevantes para os dados publicados na Web;
incentivam a publicação ou reutilização de dados na Web;
possam ser testadas por máquinas, pessoas ou por uma combinação de ambos.
Conforme mencionado acima, a avaliação de que uma Boa Prática foi seguida ou não deve ser realizada à luz do resultado pretendido e não sob a perspectiva da possível abordagem à implementação, que é indicada no detalhamento de cada Boa Prática apenas como orientação. Uma Boa Prática está sempre sujeita a melhorias, uma vez que, juntos, aprendemos e desenvolvemos a Web.
4. Contexto
Esta seção não é normativa.
O diagrama a seguir ilustra o contexto levado em consideração neste documento. Em geral, as Boas Práticas propostas para a publicação e o uso de Dados na Web tratam de conjunto de dados e distribuições. Os dados são publicados em diversas distribuições, que são a forma física específica de um conjunto de dados. Quando nos referimos a dados “queremos dizer: fatos conhecidos que podem ser gravados e que têm significado implícito” [Navathe]. Estas distribuições facilitam o compartilhamento de dados em larga escala, o que viabiliza que conjuntos de dados sejam utilizados por diversos grupos de consumidores de dados, independentemente do propósito, público, interesse ou licença. Considerando esta heterogeneidade e o fato de que os publicadores e consumidores de dados possam não se conhecer, faz-se necessário o fornecimento de algumas informações sobre os conjuntos de dados e distribuições, de forma a promover a confiabilidade e a reutilização, tais como: metadados estruturais, metadados descritivos, informações de acesso, informações de qualidade de dados, informações de procedência, informações de licença e informações de uso.
Um aspecto importante da publicação e compartilhamento de dados na Web diz respeito à base arquitetônica da Web [WEBARCH]. O princípio de identificação que diz que os URIs devem ser utilizados para identificar recursos decorre desta base arquitetônica. No nosso contexto, um recurso pode ser um conjunto de dados completo ou um item específico de um determinado conjunto de dados. Todos os recursos devem ser publicados com URIs estáveis, de forma que possam ser referenciados e compor conexões entre dois ou mais recursos por meio de URIs. Por último, para promover a interoperabilidade entre os conjuntos de dados, é importante adotar vocabulários de dados e padrões.
5. Espaços de Nome
Esta seção não é normativa.
Os seguintes prefixos de espaços de nome, do inglês namespaces, são utilizados ao longo de todo este documento.
Esta seção apresenta o modelo utilizado para descrever as Boas Práticas para Dados na Web.
Modelo de Boa Prática
Breve descrição da BP
Porque
Essa seção responde a duas perguntas cruciais:
Por que este tema é especificamente relevante para a publicação ou para o reúso de dados na Web?
Como esta iniciativa estimula a publicação ou o reúso de dados na Web?
Um texto com a descrição completa do problema abordado pela Boa Prática também pode ser fornecido. O texto pode ter qualquer tamanho, mas é provável que não tenha mais que algumas sentenças.
Resultado Pretendido
O que deve ser possível alcançar quando um publicador de dados segue as Boas Práticas.
Possível Abordagem para Implementação
Descrição de uma possível estratégia de implementação. Esta representa a melhor recomendação disponível no momento em que este documento foi escrito, mas circunstâncias específicas e desenvolvimentos futuros poderão denotar que métodos alternativos de implementação sejam mais apropriados para se obter o resultado pretendido.
Como Testar
Informações sobre como testar se a BP foi cumprida. Os testes podem ser realizados por máquinas ou não.
Evidência
Informações sobre a relevância da BP. É descrita por um ou mais requisitos relevantes, tal qual registrado no documento Requisitos e Casos de Uso das Boas Práticas para Dados na Web, do inglês Data on the Web Best Practices Use Cases & Requirements [DWBP-UCR].
Benefícios
Um benefício representa uma melhoria na forma como conjuntos de dados são disponibilizados na Web. Uma Boa Prática pode ter um ou mais benefícios.
Boa Prática 35: Citar a publicação original do conjunto de dados
8. As Boas Práticas
Esta seção apresenta as Boas Práticas a serem utilizadas por publicadores de dados para auxiliar tanto estes quanto os consumidores de dados, com vista a superar os diferentes desafios enfrentados ao se publicar e consumir dados na Web. Para cada um dos desafios uma ou mais Boas Práticas foram propostas, conforme descritas na seção Desafios de Dados na Web.
Cada BP é relacionada a um ou mais requisitos presentes no documento Requisitos e Casos de Uso das Boas Práticas para Dados na Web, do inglês Data on the Web Best Practices Use Cases & Requirements [DWBP-UCR], que serviu de guia para o seu desenvolvimento. Cada Boa Prática apresenta pelo menos um destes requisitos como evidência de sua relevância.
8.1 Exemplo de Execução
Adrian trabalha para a Agência de Transportes MyCity e é responsável pela publicação de dados sobre transporte público. Adrian quer publicar estes dados para diferentes tipos de consumidores de dados, tais como desenvolvedores interessados em criar aplicações e também para agentes de software. É importante que tanto pessoas quanto agentes de software possam compreender e processar dados com facilidade, os quais, por sua vez, devem ser mantidos atualizados e disponibilizados de modo que sejam facilmente descobertos na Web.
Exemplos em RDF da aplicação de algumas Boas Práticas são demonstrados utilizando Turtle [Turtle] ou JSON-LD [JSON-LD].
8.2 Metadados
A Web é um espaço aberto de informações, onde a ausência de um contexto específico, tal como o sistema de informações interno de uma empresa, indica que o fornecimento de metadados é um requisito fundamental. Caso os metadados fornecidos sejam insuficientes, os dados não serão descobertos ou reutilizados por ninguém além do próprio publicador. Os metadados proporcionam informações adicionais que auxiliam os consumidores de dados a compreender melhor o significado dos dados e sua estrutura, além de esclarecer outros temas, tais como direitos e termos da licença, detalhes sobre a organização que gerou os dados, a qualidade dos dados, os métodos de acesso aos dados e o agendamento da atualização dos conjuntos de dados. Os publicadores são incentivados a fornecer informações que sejam legíveis por pessoas em diversos idiomas e, na medida do possível, oferecer as informações por meio de uma linguagem (ou linguagens) que os usuários possam compreender.
Os metadados podem ser utilizados para auxiliar a realização de tarefas tais como a descoberta e reutilização de conjuntos de dados, e podem ser designados de forma a considerar diferentes níveis de granularidade: desde uma propriedade singular de um recurso, até de um conjunto de dados completo ou até mesmo de todos os conjuntos de dados de uma organização específica. Os metadados também podem ser de diversos tipos. Estes tipos podem ser classificados em taxonomias diferentes, seguindo diferentes critérios de agrupamento. Por exemplo, uma taxonomia específica poderia definir três tipos de metadados de acordo com características descritivas, estruturais e administrativas. Uma taxonomia diferente, por sua vez, poderia definir tipos de metadados de acordo com as tarefas nas quais os metadados são utilizados, como por exemplo, a descoberta e reutilização.
Boa Prática 1: Fornecer metadados
Fornecer metadados tanto para usuários pessoas quanto para aplicações de computadores.
Porque
Fornecer metadados é um requisito fundamental na publicação de dados na Web, porque os publicadores de dados e os consumidores de dados podem não se conhecer mutuamente. Portanto, é essencial fornecer informações que auxiliem pessoas e aplicações de computadores a compreenderem os dados, assim como outros aspectos importantes que descrevam o conjunto de dados ou a distribuição.
Resultado Pretendido
Pessoas serão capazes de compreender os metadados e as aplicações de computadores, especialmente agentes de software - responsáveis pela mediação do usuário com a aplicação -, serão capazes de processá-los.
Possível Abordagem para Implementação
Abordagens possíveis para fornecer metadados legíveis por pessoas:
fornecer metadados como parte de uma página Web HTML
fornecer metadados como um arquivo de texto separado
Possíveis abordagens para o fornecimento de metadados legíveis por máquina:
metadados legíveis por máquinas podem ser fornecidos em um formato seriado, tal como Turtle ou JSON, ou podem ser incorporados na página de HTML utilizando [HTML-RDFA] ou [JSON-LD]. No caso de múltiplos formatos serem publicados de forma separada, estes devem ser disponibilizados a partir do mesmo URL. Isto deve ser feito por meio de negociação de conteúdo, do inglês content negotiation (em inglês), disponibilizando-os sob URIs separados e distintos pelo nome de extensão do arquivo. A manutenção de múltiplos formatos é mais facilmente alcançada por meio da geração de cada formato disponível no momento, com base em uma única fonte de metadados.
ao definir os metadados legíveis por máquinas, recomenda-se fortemente reutilizar termos oriundos de padrões e vocabulários populares já existentes. Por exemplo, os termos [DCTERMS] Dublin Core Metadata (DCMI), e o Data Catalog Vocabulary [VOCAB-DCAT] podem ser utilizados para fornecer metadados descritivos. Tais vocabulários foram elaborados para serem extremamente flexíveis, portanto geralmente é muito conveniente utilizar um perfil específico ou um vocabulário tal qual o DCAT-AP (em inglês) da Comissão Europeia.
Como Testar
Verifique se os metadados legíveis por pessoas estão disponíveis.
Verifique se os metadados estão disponíveis em um formato válido legível por máquina e sem erros de sintaxe.
Fornecer metadados que descrevam as características gerais dos conjuntos de dados e das distribuições.
Porque
Fornecer informações descritivas de conjuntos de dados de forma explícita possibilita que agentes de software descubram automaticamente conjuntos de dados disponíveis na Web, e isto permite que pessoas compreendam a natureza do conjunto de dados e suas distribuições.
Resultado Pretendido
Pessoas serão capazes de interpretar a natureza do conjunto de dados e suas distribuições, e os agentes de software poderão automaticamente descobrir conjuntos de dados e distribuições.
Possível Abordagem para Implementação
Os metadados descritivos podem incluir as seguintes características genéricas de um conjunto de dados:
O título e a descrição do conjunto de dados.
As palavras-chave que descrevem o conjunto de dados.
A data de publicação do conjunto de dados.
A entidade responsável (publicadora de dados) por disponibilizar o conjunto de dados.
O ponto de contato para o conjunto de dados.
A cobertura espacial do conjunto de dados.
O período temporal coberto pelo conjunto de dados.
A data da última modificação do conjunto de dados.
Os temas/categorias cobertos por um conjunto de dados.
Os metadados descritivos podem incluir as seguintes características genéricas de uma distribuição:
O título e a descrição da distribuição.
A data da publicação da distribuição.
O formato de mídia da distribuição.
A versão legível por máquina dos metadados descritivos pode ser disponibilizada utilizando o vocabulário recomendado pelo W3C para descrever conjuntos de dados, como, por exemplo, o Data Catalog Vocabulary [VOCAB-DCAT]. Isto estabelece uma estrutura na qual os conjuntos de dados podem ser descritos como entidades abstratas.
Como Testar
Verifique se os metadados do conjunto de dados incluem as características genéricas do conjunto de dados em formato legível por pessoas.
Verifique se os metadados descritivos estão disponíveis em um formato válido legível por máquina.
Fornecer metadados que descrevam o esquema e a estrutura interna de uma distribuição.
Porque
Fornecer informações sobre a estrutura interna de uma distribuição é fundamental para outros que desejem explorar ou consultar o conjunto de dados. Também auxilia as pessoas a compreender o significado dos dados.
Resultado Pretendido
Pessoas serão capazes de interpretar o esquema de um conjunto de dados e os agentes de software serão capazes de processar as distribuições automaticamente.
Possível Abordagem para Implementação
Os metadados estruturais legíveis por pessoas geralmente fornecem as propriedades ou as colunas do esquema do conjunto de dados.
Os metadados estruturais legíveis por máquina são disponibilizados de acordo com o formato de uma distribuição específica e podem ser fornecidos dentro de documentos separados ou incorporados ao documento. Para maiores detalhes, acesse os links abaixo:
Verifique se os metadados estruturais estão disponibilizados em um formato legível por pessoas.
Verifique se os metadados da distribuição incluem as informações estruturais sobre o conjunto de dados em um formato legível por máquina e sem erros de sintaxe.
A licença é uma informação muito útil e deve ser anexada aos dados na Web. Dependendo do tipo de licença adotado pelo publicador, pode haver mais ou menos restrições no que diz respeito ao compartilhamento e à reutilização dos dados. No contexto dos dados na Web, a licença de um conjunto de dados pode ser especificada dentro ou fora dos metadados, ou em um documento separado ao qual esteja conectado.
Boa Prática 4: Fornecer informações sobre a licença de dados
Fornecer um link ou uma cópia dos termos da licença que controla a utilização dos dados.
Porque
Disponibilizar informações de licença é fundamental para que os consumidores de dados avaliem a utilidade dos dados. Os agentes de software podem utilizar a presença/ausência das informações de licença como um gatilho para a inclusão ou exclusão de dados apresentados a um consumidor em potencial.
Resultado Pretendido
Pessoas serão capazes de compreender a licença de dados, que descreve eventuais restrições impostas à utilização de certos dados, e agentes de software serão capazes de detectar automaticamente a licença de dados de uma distribuição.
Possível Abordagem para Implementação
As informações sobre a licença de dados podem ser disponibilizadas por meio de um link ou de uma cópia embutida dos termos da licença que seja legível por pessoas. Também podem ser disponibilizadas para processamento um link ou cópia embutida dos termos da licença legível por máquina.
Os seguintes vocabulários, que incluem propriedades para vincular uma licença, podem ser usados:
A Web reúne negócios, engenharia, comunidades científicas e cria oportunidades colaborativas anteriormente inimagináveis. O desafio da publicação de dados na Web é disponibilizar um detalhamento adequado da origem dos mesmos. O produtor de dados pode não ser necessariamente o publicador de tais dados e, portanto, é importante coletar e transmitir os metadados correspondentes. Sem a procedência, os consumidores não dispõem de meios para confiar na integridade e credibilidade dos dados que estão sendo compartilhados. Por sua vez, os publicadores de dados precisam estar cientes das necessidades das potenciais comunidades de consumidores para poder adequar os detalhes de procedência.
Boa Prática 5: Fornecer informações de procedência dos dados
Fornecer informações completas sobre as origens dos dados e de quaisquer alterações que você tenha feito.
Porque
A procedência é uma das formas que os consumidores dispõem para julgar a qualidade de um conjunto de dados. Entender sua origem e história auxilia a determinar se o dado é confiável e fornece um contexto para interpretação dos dados importante.
Resultado Pretendido
Pessoas saberão a origem e o histórico do conjunto de dados e os agentes de software poderão automaticamente processar a informação de procedência.
Possível Abordagem para Implementação
A versão legível por máquina da procedência de dados pode ser disponibilizada por meio de uma ontologia recomendada para descrever informações de procedência, tais como a Provenance Ontology do W3C [PROV-O].
Como Testar
Verifique se os metadados do conjunto de dados incluem informações de procedência sobre o conjunto de dados em um formato legível por pessoas.
Verifique se uma aplicação de computador pode processar automaticamente as informações sobre a procedência do conjunto de dados.
A qualidade de um conjunto de dados pode ter um grande impacto na qualidade das aplicações que o utilizam. Como consequência, é de fundamental importância a inclusão de informações sobre a qualidade dos dados na publicação de dados e em sua distribuição para consumo. Normalmente, a avaliação da qualidade envolve diferentes dimensões de qualidade, cada qual representando grupos de características que são relevantes para publicadores e consumidores. O Data Quality Vocabulary define conceitos tais como as medidas e métricas para avaliação da qualidade de cada dimensão [VOCAB-DQV]. Existem métodos inteligentes, que adequam-se a situações específicas de avaliação que dependem de indicadores de qualidade, tais como fragmentos de conteúdos de dados, fragmentos de dados de meta informação, e classificações realizadas por pessoas que atribuam indicadores sobre a pertinência dos dados para alguns dos usos pretendidos.
Boa Prática 6: Fornecer informações de qualidade de dados
Fornecer informações sobre a qualidade dos dados e adequação para fins específicos.
Porque
A qualidade dos dados pode afetar seriamente o uso dos dados para aplicações específicas, incluindo aplicações bem diferentes do propósito para o qual estas foram originalmente criadas. Documentar a qualidade dos dados facilita significativamente o processo de seleção de conjuntos de dados, aumentando as chances de reutilização dos mesmos. Independentemente das peculiaridades específicas do domínio, a qualidade dos dados deve ser documentada e os problemas de qualidade que são conhecidos devem ser declarados de forma explícita nos metadados.
Resultado Pretendido
Pessoas e agentes de software serão capazes de avaliar a qualidade e, portanto, a adequação de um conjunto de dados para a sua aplicação.
Possível Abordagem para Implementação
A versão legível por máquina dos metadados de qualidade do conjunto de dados pode ser fornecida utilizando o vocabulário Data Quality Vocabulary desenvolvido pelo grupo de trabalho DWBP [VOCAB-DQV].
Como Testar
Verifique se os metadados do conjunto de dados incluem informações sobre a qualidade deste determinado conjunto de dados.
Verifique se uma aplicação de computador pode processar automaticamente as informações sobre a qualidade do conjunto de dados.
Os conjuntos de dados publicados na Web podem mudar ao longo do tempo. Alguns conjuntos de dados são atualizados regularmente e outros são alterados à medida que melhorias na coleta de dados fazem as atualizações valerem a pena. Com o objetivo de lidar com estas mudanças, novas versões de um conjunto de dados podem ser criadas. Infelizmente não há consenso sobre em qual momento, por conta das alterações em um conjunto de dados, o mesmo deve ser considerado como um conjunto de dados completamente diferente e não somente uma nova versão. A seguir, apresentamos alguns cenários nos quais a maioria dos publicadores concordaria que, com as alterações, deveria ser considerada uma nova versão de um conjunto de dados já existente.
Cenário 1: foi instalada uma nova parada de ônibus que deve ser adicionada ao conjunto de dados;
Cenário 2: uma parada de ônibus já existente foi removida e deve ser excluída do conjunto de dados;
Cenário 3: foi identificado um erro em uma das paradas de ônibus existentes armazenada no conjunto de dados, e este erro deve ser corrigido.
Em geral, múltiplos conjuntos de dados que representam séries temporais ou espaciais - por exemplo, o mesmo tipo de dados para diferentes regiões ou para anos diferentes - não são considerados múltiplas versões do mesmo conjunto de dados. Neste caso cada conjunto de dados cobre um conjunto diferente de observações sobre o mundo e, então, deve ser tratado como um novo conjunto de dados. Este também é o caso de um conjunto de dados que coleta dados sobre as previsões meteorológicas semanais para uma determinada cidade, onde toda semana um novo conjunto de dados é criado para armazenar dados sobre aquela semana especificamente.
Os Cenários 1 e 2 podem desencadear uma versão principal, enquanto o Cenário 3 provavelmente desencadearia somente uma versão a mais. No entanto, decidir se as versões devem ser principais ou não é menos importante do que realizar qualquer alteração sem incrementar o indicador de versão. Até mesmo para pequenas alterações é importante que se mantenha um registro das diferentes versões do conjuntos de dados de forma a tornar o conjunto de dados confiável. Os publicadores devem lembrar que um determinado conjunto de dados pode ser utilizado por um ou mais consumidores de dados, então devem tomar medidas sensatas para informar os consumidores quando uma nova versão é lançada. Para dados em tempo real, uma marca temporal automatizada pode servir como identificador de versão. Para cada conjunto de dados o publicador deve abordar o versionamento de forma consistente e informativa de modo que os consumidores de dados possam compreender e trabalhar com os dados alterados.
Boa Prática 7: Fornecer indicador de versão
Designar e indicar um número de versão ou data para cada conjunto de dados.
Porque
As informações sobre a versão tornam a revisão de um conjunto de dados identificável de forma única. Esta unicidade pode ser utilizada pelos consumidores de dados para determinar especificamente com qual versão de um conjunto de dados estão trabalhando. O bom versionamento dos dados possibilita aos consumidores entender se uma nova versão de um conjunto de dados está disponível. O versionamento explícito leva em conta a repetitividade na pesquisa, permite comparações e evita confusão. A utilização de números únicos de versão com uma abordagem padronizada também pode contribuir na expectativas do consumidor, acerca da diferença entre versões.
Resultado Pretendido
Pessoas e agentes de software poderão facilmente identificar com qual versão do conjunto de dados estão trabalhando.
Possível Abordagem para Implementação
O melhor método para o fornecimento de informações sobre o versionamento irá variar de acordo com o contexto. No entanto, existem algumas diretrizes básicas que podem ser seguidas, como por exemplo:
Incluir um único número de versão ou data como parte dos metadados para o conjunto de dados.
Utilizar um mecanismo numérico consistente com uma abordagem significativa para incrementar dígitos, tal como [SchemaVer].
Caso os dados estejam sendo disponibilizados por meio de uma API, o URI utilizado para solicitar a versão mais recente dos dados não deve ser alterado à medida em que as versões se modifiquem. Porém deve ser possível requisitar uma versão específica por meio de uma API.
Utilizar Memento [RFC7089], ou seus componentes para evidenciar o versionamento temporal de um conjunto de dados e para acessar a versão que estava operante em uma determinada data e hora. O protocolo Memento alinha-se intimamente com a abordagem para designação de URIs para versões que são utilizadas nas especificações do W3C, descritas abaixo.
A Web Ontology Language [OWL2-QUICK-REFERENCE] e a Provenance, Authoring and versioning Ontology [PAV] fornecem uma série de propriedades de anotações para a informação sobre versões.
Como Testar
Verifique se os metadados para o conjunto de dados ou distribuição fornece um número de versão ou data específico em um formato legível por pessoas.
Verifique se a aplicação de computador pode detectar/descobrir automaticamente o número de versão ou data específicos de um conjunto de dados ou uma distribuição, e se pode processá-lo.
Fornecer um histórico completo de versão que explique as alterações feitas em cada versão.
Porque
Ao criar aplicações que utilizam dados é útil compreender a variação destes ao longo do tempo. A interpretação de dados também é potencializada pela compreensão de sua dinâmica. Determinar como diversas versões de um conjunto de dados diferenciam umas das outras é geralmente muito trabalhoso, a não ser que um sumário destas diferenças seja fornecido.
Resultado Pretendido
Pessoas e os agentes de software serão capazes de entender como o conjunto de dados se altera tipicamente de versão à versão, assim como poderão especificar como duas versões em particular diferenciam-se uma da outra.
Possível Abordagem para Implementação
Fornecer uma lista de versões publicadas e uma descrição para cada versão que explique como esta difere da anterior. Uma API pode demonstrar o histórico da versão como um único URL dedicado que recupere a última versão a partir do histórico completo.
Como Testar
Verifique se uma lista das versões já publicadas está disponível assim como o histórico de modificações, do inglês change log. Este último deve descrever exatamente em que cada uma das novas versões difere da versão anterior.
Identificadores assumem diversas formas e são extensivamente utilizados em todos os sistemas de informação. A descoberta de dados, o uso e a citação na Web dependem fundamentalmente do uso de URIs HTTP (ou HTTPS): identificadores globalmente únicos que podem ser buscados ao serem desreferenciados por meio da Internet [RFC3986]. Talvez seja válido enfatizar alguns pontos-chave sobre os URIs no presente contexto:
URIs são “strings burros”, do inglês dumb strings, o que quer dizer que não carregam nenhuma semântica. Sua função é puramente identificar um recurso.
Embora seja verdadeiro o ponto anterior, seria perverso para um URI tal qual https://example.com/dataset.csv retornar nada além de do que um arquivo CSV. É recomendável que seja legível por pessoas.
Ao ser dereferenciado (buscado), um único URI pode oferecer o mesmo recurso em mais de um formato. https://example.com/dataset pode oferecer os mesmos dados em CSV, JSON e XML, por exemplo. O servidor retorna o formato mais apropriado com base na negociação de conteúdo (em inglês).
Um URI pode redirecionar-se a outro.
Dereferenciar um URI aciona a execução de um programa de computador em um servidor que pode fazer algo tão simples como retornar um arquivo único e estático, ou pode realizar processamentos complexos. Precisamente qual processamento é realizado - por exemplo, o software no servidor - é completamente independente do URI em si.
Boa Prática 9: Usar URIs persistentes como identificadores de conjuntos de dados
Identificar cada conjunto de dados por meio de um URI persistente e cuidadosamente escolhido.
Porque
Adotar um sistema de identificação comum permite a identificação básica dos dados e a comparação dos processos por qualquer um dos atores envolvidos de forma confiável. São pré-condições essenciais para o gerenciamento e reutilização dos dados de forma adequada.
Os desenvolvedores podem construir URIs dentro de seus códigos e, para isso, é importante que tais URIs sejam persistentes e que desreferenciem para o mesmo recurso ao longo do tempo, sem a necessidade de intervenção humana.
Resultado Pretendido
Os conjuntos de dados ou as informações sobre os conjuntos de dados serão encontrados e citados com facilidade em qualquer momento, independentemente do status, da disponibilidade ou do formato dos dados.
Possível Abordagem para Implementação
Para serem persistentes os URIs devem ser designadas como tal. Muito já foi escrito sobre este tópico, veja por exemplo o Estudo da Comissão Europeia sobre URIs Persistentes [PURI] que por sua vez propõe conexões a muitos outros recursos.
No caso de um publicador de dados não ser capaz ou estiver relutante em gerenciar um espaço de URI diretamente para persistência, uma abordagem alternativa seria utilizar um serviço de redirecionamento tal qual Permanent Identifiers for the Web (em inglês) ou purl.org (em inglês). Estes oferecem URIs persistentes que podem ser redirecionados conforme necessário de forma que a eventual localização possa ser efêmera. O software por trás destes serviços (em inglês) encontra-se disponível gratuitamente e, portanto, pode ser instalado e gerenciado localmente caso necessário.
Identificadores de Objetos Digitais (DOIs, em inglês) oferecem uma alternativa similar. Estes identificadores são definidos independentemente de qualquer tecnologia Web, mas podem ser anexados a um stub URI, uma ponta de URI. Os DOIs são parte importante da infraestrutura digital para a pesquisa de dados e bibliotecas.
Como Testar
Verifique se cada conjunto de dados encontra-se identificado utilizando um URI que tenha sido designado para ser persistente. O ideal é que o sítio Web relevante inclua uma descrição de uma esquema de design e uma proposta plausível de persistência caso o publicador não puder manter o espaço URI por si só.
Boa Prática 10: Usar URIs persistentes como identificadores dentro de conjuntos de dados
Reutilizar os URIs de terceiros como identificadores dentro dos conjuntos de dados quando possível.
Porque
O poder da Web reside no Efeito de Rede. O primeiro telefone somente tornou-se útil quando um segundo telefone abriu a possibilidade de ter alguém para telefonar; o terceiro telefone tornou os dois primeiros ainda mais úteis. Os dados tornam-se mais valiosos caso refiram-se a dados de outras pessoas sobre o mesmo tema, o mesmo local, o mesmo conceito, o mesmo evento, a mesma pessoa, e assim por diante.
Isto significa utilizar os mesmos identificadores por meio de diversos conjuntos de dados e garantir que os seus identificadores possam ser referidos por outros conjuntos de dados. Quando tais identificadores são URIs HTTP, estes podem ser consultados e mais dados podem ser descobertos.
Estas ideias são o foco central das Cinco Estrelas dos Dados Conectados, do inglês 5 Stars of Linked Data (em inglês), onde um ponto de dados conecta-se a outro, e do Hypermedia (em inglês), onde links podem ser utilizados por serviços que podem atuar ou se relacionar com os dados de alguma forma.
Isto é a Web dos Dados.
Resultado Pretendido
Os itens dos dados serão relacionados por meio da Web criando um espaço de informação global, acessível tanto para pessoas quanto para máquinas.
Possível Abordagem para Implementação
Este é um tópico em si mesmo, e um documento genérico como este comporta somente um detalhamento superficial.
Os desenvolvedores sabem que muito frequentemente o problema que estão tentando resolver já foi solucionado por outras pessoas. Da mesma forma, caso você esteja buscando um conjunto de identificadores para coisas padronizadas tais como países, moedas correntes, disciplinas, espécies, proteínas, cidades e regiões, ganhadores de Prêmios Nobel e produtos - alguém já percorreu o mesmo caminho. Os passos descritos em descobrindo vocabulários já existentes (em inglês) [LD-BP] podem ser prontamente adaptados.
certifique-se de que os conjuntos de URIs que você utiliza tenham sido publicados por um grupo ou uma organização confiável;
certifique-se de que os conjuntos de URIs são de URIs persistentes.
Caso não seja possível encontrar um conjunto de identificadores já existente e que atenda às suas necessidades, será preciso criar o seu próprio conjunto seguindo os padrões para persistência do URI, de forma que outros possam adicionar valor aos seus dados ao estabelecer conexões com os mesmos.
Como Testar
Verifique se dentro do conjunto de dados as referências à elementos que não se modificam ou que se modificam lentamente - tais como países, regiões, organizações e pessoas - são referenciados por meio de URIs ou por identificadores curtos que possam ser anexados a um stub URI. A princípio os URIs deveriam solucionar, no entanto eles têm valor como variáveis de escopo global, sejam elas resolvidas ou não.
Boa Prática 11: Atribuir URIs para as versões dos conjuntos de dados e séries
Atribuir URIs a versões individuais de conjuntos de dados assim como a séries em geral.
Porque
Assim como documentos, muitos conjuntos de dados são naturalmente passíveis de serem categorizados em séries ou grupos. Por exemplo:
paradas de ônibus em MyCity (que se modificam ao longo do tempo);
uma listagem dos representantes eleitos em MyCity;
versões de um documento em progresso até sua conclusão.
Em diferentes circunstâncias seria apropriado fazer uma referência à situação corrente (o conjunto de paradas de ônibus atuais, os representantes eleitos atuais, etc.). Em outras, pode ser apropriado fazer referência à situação tal como ela se apresentava em um momento específico.
Resultado Pretendido
Pessoas e agentes de software serão capazes de recorrer a versões específicas de um conjunto de dados e a conceitos tais como “séries de conjuntos de dados” e “a versão mais recente”.
Possível Abordagem para Implementação
O W3C fornece um bom exemplo sobre como fazê-lo. O URI (persistente) para este documento (em inglês) é https://www.w3.org/TR/2016/PR-dwbp-20161215/. Este identificador aponta para um snapshot (registro dos dados em um determinado momento imutável) deste documento no dia de sua publicação. O URI para a 'versão mais recente' deste documento (em inglês) é https://www.w3.org/TR/dwbp/, o qual é um identificador para o próprio documento, que está sujeito à alterações ao longo do tempo. No momento da publicação ambos URIs indicavam para este documento. No entanto, quando a próxima versão deste documento for publicada, o URI da 'versão mais recente' será alterado e redirecionado àquele; o URI datado, porém, permanecerá inalterado.
Como Testar
Verifique se cada versão do conjunto de dados possui seu próprio URI e também se a 'versão mais recente' do URI está disponível.
O formato no qual os dados são disponibilizados aos consumidores é um aspecto chave para garantir que os dados sejam passíveis de serem usados. O melhor e mais flexível mecanismo de acesso a dados do mundo é inútil caso não se disponibilize dados em formatos que permitam seu uso e reúso. Abaixo detalhamos as Boas Práticas para selecionar formatos para os seus dados, tanto em nível de arquivos quanto de campos individuais. O W3C incentiva o uso de formatos que possam ser utilizados por um público mais amplo possível e que possam ser processados de forma simples por sistemas computacionais. Formatos de fontes, tais como os depósitos de bases de dados ou de planilhas, utilizados para gerar o formato final a ser publicado, estão fora do escopo. Este documento trata do que de fato foi publicado e não de sistemas internos utilizados para gerar os dados publicados.
Boa Prática 12: Usar formatos de dados padronizados legíveis por máquinas
Disponibilize os dados em um formato padronizado e legível por máquinas que seja apropriado para seu propósito ou uso em potencial.
Porque
Na medida que os dados passam a ser mais ubíquos e os conjuntos de dados maiores e mais complexos, o processamento por computadores torna-se a cada dia mais relevante. Disponibilizar dados em um formato que não seja legível por máquinas impõe severas limitações para a utilidade dos dados. Os dados tornam-se úteis ao serem processados e transformados em informação. Observe que há uma importante distinção entre formatos que podem ser lidos e editados por pessoas utilizando um computador e formatos que são legíveis por máquinas. O último termo implica que os dados sejam prontamente extraídos, transformados e processados por um computador.
Utilizar formatos de dados não padronizados é caro e ineficiente, e os dados podem perder significado conforme são transformados. Em contrapartida, formatos de dados padronizados viabilizam tanto a interoperabilidade quanto usos futuros, tais como a remixagem ou a visualização, muitos dos quais não podem ser antecipados quando os dados são publicados pela primeira vez. Também é importante observar que a maior parte dos formatos padronizados que são legíveis por máquinas também são neutros no que se refere à localidade.
Resultado Pretendido
Máquinas serão capazes de ler e processar facilmente os dados publicados na Web e as pessoas poderão utilizar as ferramentas computacionais usualmente disponíveis para trabalhar com dados.
Possível Abordagem para Implementação
Disponibilize os dados em um formato padronizado e legível por máquinas, que seja facilmente analisável e que inclua, mas não se limite, à serialização de sintaxes CSV, XML, HDF5, JSON e RDF como RDF/XML, JSON-LD ou Turtle.
Como Testar
Verifique se o formato de dados está em conformidade com as especificações de um formato de dados legível por máquinas.
Boa Prática 13: Usar representações de dados que sejam independentes de localidade (locale neutral)
Utilize estruturas e conteúdo de dados de localidade neutra ou, quando isso não for possível, forneça metadados sobre os parâmetros regionais dos conteúdos de dados.
Porque
Dados cujos conteúdos são legíveis por máquinas e não são específicos de nenhum idioma ou cultura em particular são mais duráveis e menos suscetíveis a interpretações errôneas do que dados que usam uma das muitas possíveis interpretações culturais em seus conteúdos. Coisas como datas, moedas e números podem soar parecidas, mas têm significados diferentes em locais distintos. Por exemplo, a 'data' 4/7 tanto pode ser lida como 04 de julho ou como 07 de abril, dependendo de onde os dados foram criados. Da mesma forma, €2,000 pode tanto significar dois mil Euros quanto uma representação excessivamente precisa de dois Euros. Utilizar um formato de localidade neutra evita a necessidade de estabelecer regras intercambiáveis específicas que variam de acordo com o idioma ou com a localização do usuário. Quando os dados já estão em um formato de localidade específica, explicitar o local e a linguagem por meio do fornecimento de parâmetros de localidade permite aos usuários determinar se poderão trabalhar com os dados e habilitar serviços de tradução automatizados prontamente ou não.
Resultado Pretendido
Pessoas e agentes de software serão capazes de interpretar o significado de strings que representam datas, horários, moedas, números, etc., de forma precisa.
Possível Abordagem para Implementação
Os formatos de serialização de dados mais comuns são de localidade neutra. Por exemplo, tipos XML Schema como xsd:integer e xsd:date destinam-se a intercâmbios de dados de localidade neutra. Utilizar representações de localidade neutra permite que os conteúdos dos dados sejam processados de forma precisa sem análises complexas ou interpretações errôneas, e também permite que os dados sejam apresentados em um formato mais confortável aos consumidores de dados em qualquer localidade. Por exemplo, em vez de armazenar "€2000,00" como um string é altamente preferível substituir por uma estrutura de dados tal como:
O conteúdo de alguns conjuntos de dados não são ou não podem ser disponibilizados em um formato de localidade neutra. Isto é particularmente verdadeiro para todos os dados com conteúdo de texto em linguagem natural. Para cada campo de dados que possa conter textos afetados por conta da localidade ou de linguagem natural, deverá ser associada uma tag (etiqueta) do idioma, a qual indica o idioma e a localização do dado. O consumidor de dados pode usar essa informação de localidade tanto para analisar os dados quanto para garantir uma apresentação e processamento adequados do conteúdo. A BCP47 [BCP47] fornece o padrão para a identificação do idioma e da localidade e, de maneira informativa, o repositório CLDR [CLDR] é a fonte tanto para representação de formatos de localidades específicas, quanto para referências de conteúdos de dados de locais específicos.
Como Testar
Verifique se os dados com conteúdo sensíveis à localidade estão representados em um formato de localidade neutra ou que, caso isso não seja possível, sejam fornecidos metadados de localidade relevante.
Boa Prática 14: Fornecer dados em formatos múltiplos
Disponibilize os dados em vários formatos quando mais de um formato for adequado ao potencial ou pretendido uso do dado.
Porque
Disponibilizar dados em mais de um formato reduz os custos decorrentes da transformação de dados e minimiza a possibilidade de erros no processo de transformação. Caso muitos usuários precisem transformar os dados em um formato específico, publicá-los neste formato desde o início poupa tempo, dinheiro e evita erros de uma forma mais eficiente. Por último, aumenta o número de ferramentas e aplicações que podem processar os dados.
Resultado Pretendido
O maior número possível de usuários será capaz de utilizar os dados sem ter que primeiramente transformá-los para seu formato de preferência.
Possível Abordagem para Implementação
Considere os formatos de dados que provavelmente serão necessários e também alternativas que possivelmente serão úteis no futuro. Os publicadores de dados devem equilibrar o esforço necessário para disponibilizar os dados em muitos formatos com relação ao custo de fazê-lo; no entanto, fornecer pelo menos uma alternativa aumentará significativamente a utilidade dos dados. Para disponibilizar dados em mais de um formato você pode utilizar negociação de conteúdo conforme descrito na Boa Prática Usar negociação de conteúdo para disponibilizar dados em formatos múltiplos.
Um aviso: identificadores de localidade dentro de conjuntos de dados, que podem ser expostos como identificadores de fragmentos em URIs, devem ser consistentes nos vários formatos.
Como Testar
Verifique se o conjunto de dados completo está disponível em mais de um formato de dados.
Vocabulários (em inglês) definem os conceitos e as relações (também conhecidas como 'termos' ou 'atributos') utilizados para descrever e representar uma área de interesse. São utilizados para classificar os termos que podem ser utilizados em uma aplicação específica, caracterizar possíveis relações, e definir possíveis limitações na utilização destes termos. Vários sinônimos próximos de 'vocabulário' já foram cunhados, como por exemplo, ontologia, vocabulário controlado, glossário, taxonomia, lista de códigos, rede semântica.
Não há uma divisão precisa entre os artefatos referidos por estas denominações. No entanto, 'Ontologia' tende a denotar vocabulários de classes e propriedades que estruturam as descrições de recursos em conjuntos de dados (conectados). Em bases de dados relacionais, estes correspondem a nomes de tabelas e colunas; em XML, correspondem aos elementos definidos por um Schema XML. As ontologias são os principais blocos de construção para técnicas de inferência na Web Semântica. O primeiro meio oferecido pelo W3C para a criação de ontologias é RDF Schema [RDF-SCHEMA]. É possível definir ontologias mais expressivas com axiomas adicionais utilizando linguagens tais como as da Ontologia de Linguagens Web [OWL2-OVERVIEW].
Por outro lado, 'vocabulários controlados', 'esquematizações conceituais' e 'sistemas de organização de conhecimento' enumeram e definem recursos que podem ser empregados nas descrições realizadas com o tipo de vocabulário prévio como, por exemplo, vocabulários que estruturam as descrições de recursos em conjuntos de dados (conectados). Um conceito advindo de um glossário, como 'arquitetura', será utilizado, por exemplo, no campo de assunto para a descrição de um livro, (onde 'assunto' tenha sido definido em uma ontologia para livros). Geralmente não são necessários formalismos complexos para definir termos nestes vocabulários. Modelos mais simples foram propostos para representá-los e substituí-los, tais como o modelo de dados ISO 25964 [ISO-25964] ou o Simple Knowledge Organization System do W3C [SKOS-PRIMER].
Boa Prática 15: Reutilizar vocabulários, dando preferência aos padronizados
Utilize termos oriundos de vocabulários compartilhados, preferencialmente os padronizados, para codificar dados e metadados.
Porque
A utilização de vocabulários já em uso por outros estimula e facilita o consenso em comunidades. Aumenta a interoperabilidade e reduz as redundâncias, incentivando assim a reutilização de seus próprios dados. Particularmente, a aplicação de vocabulários compartilhados para metadados (especialmente os metadados estruturais, de procedência, de qualidade e de versionamento) auxilia o processo de comparação e o processamento automático - tanto dos dados quanto dos metadados. Além disso, a referência a códigos e termos padronizados ajuda a evitar ambiguidade e conflitos entre elementos e valores similares.
Resultado Pretendido
Melhorar a interoperabilidade e o consenso entre os publicadores e consumidores de dados.
Possível Abordagem para Implementação
A seção de Vocabulários (em inglês) no documento Best Practices for Publishing Linked Data [LD-BP] do W3C fornece orientação sobre a descoberta, avaliação e seleção de vocabulários existentes.
Organizações tais como a Open Geospatial Consortium (OGC), ISO, W3C, WMO, bibliotecas e serviços de pesquisa de dados, etc., disponibilizam listas de códigos, terminologias e vocabulários de Dados Conectados que podem ser utilizados por todos. Uma questão fundamental é garantir que o conjunto de dados, ou sua documentação, forneça contextualização suficiente (tanto em formatos legíveis por pessoas e por máquinas) para que os consumidores de dados possam recuperar e explorar o significado padronizado dos valores. No contexto da Web uma forma eficiente de fazer isto é utilizar identificadores (URIs) baseados na Web para recursos de vocabulário padronizado, tendo em mente que o mesmo URI pode ter rótulos multilíngues anexados para uma maior interoperabilidade em diferentes países. O glossário multilíngue da União Europeia, Eurovoc (em inglês), fornece um exemplo excelente.
Como Testar
Utilize repositórios de vocabulários como o repositório Linked Open Vocabularies (em inglês) ou listagens de serviços mencionados em documentos de Boas Práticas específicas de tecnologia, tais como o Best Practices for Publishing Linked Data [LD-BP] ou o Core Initial Context for RDFa and JSON-LD (em inglês); certifique-se de que as classes, propriedades, termos, elementos ou atributos utilizados para representar um conjunto de dados não repliquem aqueles definidos por vocabulários utilizados para outros conjuntos de dados.
Verifique se os termos ou códigos no vocabulário a serem utilizados estão definidos em uma organização de desenvolvimento de padrões tal como IETF, OGC e W3C etc., ou tenham sido publicados por uma autoridade adequada, tais como agências governamentais.
Boa Prática 16: Escolher o nível de formalização adequado
Escolha um nível de semântica formal que se ajuste tanto aos dados quanto às aplicações mais prováveis de serem utilizadas.
Porque
Como Albert Einstein pode ou não ter dito: tudo deve ser feito da forma mais simples o possível, mas não de forma simplória.
A semântica formal auxilia a estabelecer especificações precisas que transmitam significados detalhados e, por um lado, utilizar um vocabulário complexo (ontologia), pode servir como base para tarefas tais como o raciocínio automatizado. Por outro lado, tais vocabulários complexos exigem mais esforços de produção e compreensão, o que pode dificultar seu reúso, sua comparação e conexão com bases de dados que os utilizem.
Caso os dados sejam suficientemente ricos, a ponto de permitir perguntas de pesquisa detalhadas (o fato de A, B e C serem verdadeiros e D, falso, leva à conclusão E), então algo semelhante ao Perfil OWL seria bastante apropriado [OWL2-PROFILES].
No entanto, não há nada de complicado em listagens de pontos de ônibus.
Escolher um vocabulário muito simples é sempre atrativo, mas há um perigo: o desejo de manter a simplicidade pode induzir o publicador a omitir alguns dados que fornecem informações importantes, tais como a localização geográfica dos pontos de ônibus, o que impediria que fossem exibidos em um mapa. Portanto, o equilíbrio deve ser atingido tendo em mente que o objetivo não é simplesmente compartilhar seus dados, mas que outros possam reutilizá-los.
Resultado Pretendido
As aplicações mais prováveis serão suportadas sem um grau de complexidade maior que o necessário.
Possível Abordagem para Implementação
Observe o que os seus pares já vêm fazendo. É provável que você irá se deparar com um vocabulário utilizado com frequência, que vem ao encontro de suas necessidades - mesmo que de forma aproximada. Provavelmente este é o vocabulário a ser utilizado.
Talvez você encontre um vocabulário que gostaria de utilizar, mas perceba uma restrição semântica que dificulta fazê-lo, como um domínio ou um grupo de restrições que não se aplica ao seu caso. Neste cenário, muitas vezes vale a pena entrar em contato com o editor do vocabulário para conversar sobre isso. É possível que os editores consigam remover tais restrição e proporcionar uma orientação adicional sobre como o vocabulário é utilizado de forma mais ampla.
O W3C disponibiliza uma lista de discussão em [email protected] [arquivo (em inglês)] onde questões referentes ao uso e desenvolvimento dos vocabulários são discutidas.
Caso esteja criando seu próprio vocabulário, mantenha as restrições semânticas ao mínimo que atenda às suas necessidades de modo a, novamente, incentivar a possibilidade de reúso por terceiros. Como exemplo, os designers da ontologia SKOS (muito utilizada), minimizaram seu compromisso ontológico questionando todos os axiomas formais sugeridos para suas classes e propriedades. Muitas vezes estes foram rejeitados porque seu uso, embora benéfico para muitas aplicações, criaria inconsistências formais para os dados de outras aplicações, o que tornaria a ontologia SKOS inteiramente não utilizável para estas. A propriedade skos:broader, por exemplo, não foi definida como uma propriedade transitiva, muito embora teria se adequado à forma como links hierárquicos entre conceitos são criados em muitos glossários [SKOS-DESIGN]. Ao selecionar um vocabulário busque evidências do tipo 'design para amplo uso'.
Outro exemplo de 'design para amplo uso' pode ser encontrado no schema.org. Lançado em junho de 2011, schema.org foi adotado massivamente em pouco tempo em parte por conta de sua abordagem informativa - e não normativa - para definir os tipos de objetos com os quais as propriedades podem ser usadas. Por exemplo, os valores da propriedade autor são apenas 'esperados' que sejam do tipo Organização ou Pessoa. No tipo CreativeWork, 'pode ser usado' Autor, mas esta não é uma restrição rigorosa. Novamente, esta abordagem de design torna o schema.org uma boa escolha como vocabulário a ser usado ao codificar dados para compartilhamento.
Como Testar
Esta é quase sempre uma questão de análise subjetiva, para a qual não há um teste objetivo. Como diretriz geral:
Vocabulários comuns, como o Dublin Core e o schema.org, estão sendo utilizados?
Os fatos estão declarados de forma simples e podem ser facilmente recuperados?
Para linguagens de representação de conhecimento formal, a aplicação de um mecanismo de inferência sobre dados que usam um determinado vocabulário não produz muitas instruções desnecessárias para os aplicativos desejados.
Garantir acesso fácil aos dados na Web permite que tanto pessoas quanto máquinas beneficiem-se do compartilhamento de dados utilizando a infraestrutura Web. Por padrão, a Web oferece acesso através dos métodos do Protocolo de Transferência de Hipertexto, do inglês Hypertext Transfer Protocol (HTTP). Isto proporciona acesso aos dados em um nível atômico de transação. Este acesso pode ocorrer por meio de um simples download em massa de um arquivo ou, quando os dados são distribuídos por meio de arquivos múltiplos ou requerem métodos de recuperação mais sofisticados, por meio de uma API. Estes dois métodos básicos - download em massa e API - não são mutuamente excludentes.
No download em massa os dados geralmente estão do lado do servidor pré-processado, onde múltiplos arquivos ou árvores de diretório de arquivos são fornecidos como um único arquivo para download. Quando dados em massa estão sendo recuperados a partir de soluções de sistema que não são arquivos, dependendo das comunidades de usuários de dados, o publicador de dados pode oferecer APIs para dar suporte a uma séries de operações de recuperação, que representam uma única transação.
Para dados que são gerados em tempo real (ou quase em tempo real) os publicadores devem utilizar um sistema automatizado que permita acesso imediato a dados cronologicamente sensíveis, tais como informações sobre emergências, dados de previsão do tempo ou métricas de monitoramento do sistema. Em geral, as APIs devem ser disponibilizadas para permitir que terceiros pesquisem e recuperem automaticamente estes dados.
Além de auxiliar a automatizar as sequências de dados em tempo real, as APIs são adequadas para todos os tipos de dados na Web. Embora geralmente demande mais trabalho em relação à disponibilização de arquivos para download, os publicadores vêm progressivamente considerando que a entrega de uma API estável, bem documentada e baseada em padrões, vale o esforço.
Para alguns publicadores de dados é importante saber quem fez download dos dados e como os utilizaram. Existem duas abordagens possíveis para reunir estas informações. Primeiramente, os publicadores podem convidar os usuários a fornecê-las, de modo que a publicação continuada dos dados e a promoção de seu próprio trabalho funciona como incentivo. Uma segunda abordagem menos amistosa é exigir o registro antes que os dados possam ser acessados. Em ambos os casos, o vocabulário Dataset Usage Vocabulary [VOCAB-DUV] fornece uma estrutura para a representação de tais informações. Ao coletar dados dos usuários, o publicador deve explicar porque e como as informações coletadas dos usuários (explícita ou implicitamente) serão utilizadas. Sem uma política clara, os usuários podem ter receio de fornecer informações, o que resultaria na redução do valor do conjunto de dados.
Boa Prática 17: Fornecer download em massa (bulk download)
Permitir que os consumidores acessem o conjunto de dados completo em uma única solicitação.
Porque
Quando dados na Web estiverem distribuídos através de muitos URIs, mas podem ser organizados logicamente como um pacote, acessar os dados em massa pode ser útil. O acesso em massa garante uma forma consistente de tratar os dados como um conjunto de dados. Acessar dados individualmente ao longo de muitas consultas pode ser difícil e, caso forem usados para remontar o conjunto de dados completo, isso pode levar a uma manipulação inconsistentes dos dados.
Resultado Pretendido
Transferências de arquivos grandes, que exigiriam mais tempo do que um usuário típico consideraria razoável, serão possíveis por meio de protocolos de transferência de arquivos, do inglês file-transfer protocols (FTP)
Possível Abordagem para Implementação
Dependendo da natureza dos dados e das necessidades dos consumidores, possíveis abordagens de download em massa podem incluir:
Para conjuntos de dados que existem inicialmente como arquivos múltiplos, o pré-processamento de uma cópia dos dados em um único arquivo tornando-os acessíveis para download a partir de um URI. Para conjuntos de dados maiores, o arquivo também pode ser comprimido.
Hospedagem de uma API que permita acessar um download em massa, além de consultas dinâmicas. Este método é útil para que seja possível capturar um snapshot completo dos dados dinâmicos.
Para conjuntos de dados muito grandes, transferências de arquivos em massa podem ser viabilizados por outros meios que não HTTP, como bbcp (em inglês) ou GridFTP (em inglês).
O download em massa deve incluir os metadados que descrevem o conjunto de dados. Metadados de descoberta [VOCAB-DCAT] também devem ser disponibilizados além do download em massa.
Como Testar
Verifique se o conjunto de dados completo pode ser acessado com apenas uma única solicitação.
Boa Prática 18: Fornecer subconjuntos para conjuntos de dados extensos
Caso seu conjunto de dados seja grande, permitir que usuários e aplicações trabalhem prontamente por meio do uso de subconjuntos de seus dados.
Porque
Conjuntos de dados muito extensos podem ser difíceis de mover de um lugar para outro. Também pode ser inconveniente para os usuários armazenar ou analisar um conjunto de dados grande. Os usuários não deveriam ter que fazer download de um conjunto de dados completo caso apenas necessitem um subconjunto do mesmo. Além disso, aplicações Web que acessam conjuntos de dados grandes operam com melhor desempenho caso seus desenvolvedores consigam apropriar-se das vantagens do ‘carregamento lento’, pois é possível trabalhar com porções menores de um todo e acessar novas porções apenas quando necessário. A possibilidade de trabalhar com subconjuntos de dados também permite que o processamento offline funcione com mais eficiência. Em particular, as aplicações em tempo real beneficiam-se bastante desta possibilidade pois podem ser atualizadas mais rapidamente.
Resultado Pretendido
Pessoas e aplicações serão capazes de acessar subconjuntos de um conjunto de dados ao invés de necessariamente acessar o conjunto como um todo, com uma proporção maior de dados necessários em relação aos não necessários para o maior número de usuários. Conjuntos de dados estáticos que os usuários do domínio considerem grandes demais, serão passíveis de serem descarregados em porções menores. As APIs tornarão subconjuntos ou partes filtradas de dados disponíveis, com granularidade dependendo das necessidades do domínio e das demandas de desempenho da aplicação Web.
Possível Abordagem para Implementação
Considere os possíveis casos para os quais seu conjunto de dados será usado e determine quais tipos de subconjuntos são provavelmente os mais úteis. Uma API é normalmente a abordagem mais flexível para servir subconjuntos de dados, pois permite a personalização dos dados transferidos, tornando os subconjuntos disponíveis muito mais propensos a fornecer os dados requisitados – e poucos dados não requisitados – para qualquer situação. A granularidade deve ser adequada para velocidades de acesso de aplicações Web. (Uma chamada API que retorna dentro de um segundo permite que uma aplicação apresente uma interatividade que pareça natural. Dados que demoram mais do que dez segundos provavelmente farão com que os usuários suspeitem de falha).
Outro modo de formar subconjuntos a partir de um conjunto de dados é dividi-lo em unidades menores e tornar tais unidades disponíveis individualmente para download ou para visualizações.
Também pode ser útil marcar um conjunto de dados de forma que seções individuais (ou até mesmo porções ainda menores, se por acaso os casos de uso assim o justifiquem) possam ser processadas separadamente. Uma forma de fazê-lo é indicando “fatias” utilizando o vocabulário RDF Data Cube Vocabulary (em inglês).
Como Testar
Verifique se o conjunto de dados como um todo pode ser acessado por meio de solicitações múltiplas que acessem unidades menores.
Boa Prática 19: Usar negociação de conteúdo para disponibilizar dados em formatos múltiplos
Usar negociação de conteúdo para disponibilizar dados em formatos múltiplos, para além de extensões de arquivos.
Porque
É possível disponibilizar dados em uma página HTML com dados legíveis por pessoas mesclados a dados legíveis por máquina usando RDFa, por exemplo. No entanto, como a Arquitetura da Web [WEBARCH] e o vocabulário DCAT [VOCAB-DCAT] deixam claro, um recurso como um conjunto de dados, por exemplo, pode ter muitas representações. Os mesmos dados podem estar disponíveis em JSON, XML, RDF, CSV e HTML. Estas representações múltiplas podem ser disponibilizadas por meio de uma API, no entanto devem ser disponibilizadas a partir do mesmo URL utilizando-se a negociação de conteúdo (em inglês) para retornar a representação apropriada (o que o DCAT denomina uma distribuição). URIs específicos podem ser usados para identificar representações individuais dos dados diretamente, ignorando a negociação de conteúdo.
Resultado Pretendido
A negociação de conteúdo permitirá habilitar recursos diversos ou representações diferentes do mesmo recurso, a ser disponibilizado de acordo com a solicitação feita pelo cliente.
Possível Abordagem para Implementação
Uma abordagem possível para implementação é configurar o servidor Web para lidar com a negociação de conteúdo do recurso solicitado.
O formato específico da representação do recurso pode ser acessado pelo URI ou pelo tipo de conteúdo da Solicitação HTTP.
Como Testar
Verifique as representações disponíveis do recurso e tente obtê-las especificando o conteúdo aceito no cabeçalho da Solicitação HTTP.
Quando os dados forem produzidos em tempo real, disponibilizá-los na Web em tempo real ou quase em tempo real.
Porque
A presença de dados em tempo real na Web viabiliza o acesso a dados cronologicamente sensíveis e incentiva o desenvolvimento de aplicações Web em tempo real. O acesso em tempo real depende de que os produtores de dados em tempo real disponibilizem seus dados prontamente ao publicador de dados. A necessidade de fornecer acesso em tempo real para uma determinada aplicação precisará ser avaliada caso a caso, considerando as taxas de atualização, a latência introduzida pelos passos de pós-processamento de dados, a disponibilidade de infraestrutura e os dados de que os consumidores necessitam. Além de tornar os dados acessíveis, os publicadores de dados podem fornecer informações adicionais descrevendo lacunas, erros e anomalias de dados bem como atrasos de publicações.
Resultado Pretendido
As aplicações serão capazes de acessar dados temporalmente críticos em tempo real ou quase em tempo real, onde tempo real significa um intervalo de milissegundos até poucos segundos após a criação dos dados.
Possível Abordagem para Implementação
Uma possível abordagem para implementação é que os publicadores configurem um serviço Web que forneça uma conexão de forma que, ao receberem dados em tempo real pelo serviço Web, estes possam ser instantaneamente disponibilizados aos consumidores por polling ou streaming.
Caso os dados sejam consultados com pouca frequência pelos consumidores, os dados em tempo real poderão ser acessados após solicitação do consumidor para os dados dados mais recentes por meio de uma API. Os publicadores de dados fornecerão uma API para facilitar estas solicitações de somente de leitura.
Caso os dados sejam consultados com frequência pelos consumidores, a disponibilização dos dados por streaming poderá ser mais apropriada quando os dados forem enviados por meio de uma API. Embora técnicas de streaming não fazem parte do escopo desta boa prática, há muitos protocolos e tecnologias padronizados disponíveis (por exemplo, Server-sent Events, WebSocket, EventSourceAPI) para clientes que recebem atualizações automáticas do servidor.
Como Testar
Para testar acesso de dados em tempo real de forma adequada os dados terão que ser rastreados desde o instante em que são inicialmente coletados até o momento em que são publicados e acessados. [PROV-O] pode ser usado para descrever estas atividades. Deve-se tomar cuidado ao analisar acesso em tempo real para sistemas formados por vários sistemas de computador. Por exemplo, testes que dependam de registros temporais de relógios de parede podem refletir inconsistências entre os sistemas de computadores individuais em oposição à latência de tempo de publicação dos dados.
Disponibilizar dados de forma atualizada e explicitar a frequência de atualização
Porque
A disponibilidade dos dados na Web deve corresponder rigorosamente à data de criação ou coleta dos dados, eventualmente após estes terem sido processados ou alterados. Sincronizar cuidadosamente a publicação dos dados com a frequência de atualização incentiva a confiança do consumidor e o reúso dos dados.
Resultado Pretendido
Os dados na Web serão atualizados em tempo hábil para que a maior parte dos dados mais recentes disponibilizados online reflitam os dados mais recentes divulgados por qualquer outro canal. Quando novos dados estiverem disponíveis, serão publicados na Web o mais rapidamente possível.
Possível Abordagem para Implementação
Novas versões do conjunto de dados podem ser publicadas na Web em uma programação padrão, seguindo as Boas Práticas para Versionamento de Dados. A publicação na Web pode fazer parte do processo de lançamento de novas versões dos dados. Vincular a publicação na Web a este processo e nomear uma pessoa específica como responsável para esta tarefa pode ajudar a prevenir que os dados fiquem desatualizados. Para limitar as expectativas do consumidor por atualizações futuras, você pode incluir um texto legível por pessoas com a frequência esperada de publicação e também fornecer metadados legíveis por máquinas indicando a frequência.
Como Testar
Verifique se a frequência das atualizações encontra-se declarada e se a última cópia publicada na Web não é mais antiga do que a data prevista pela frequência de atualização declarada.
Boa Prática 22: Fornecer uma explicação para os dados que não estão disponíveis
Para dados que não estão disponibilizados fornecer uma explicação sobre como os dados podem ser acessados e quem pode fazê-lo.
Porque
Publicar documentação online sobre dados não disponíveis fornece meios para que os publicadores identifiquem explicitamente lacunas de conhecimento. Isto fornece uma explicação contextual para comunidades de consumidores e desta forma incentiva o uso dos dados que estão disponíveis.
Resultado Pretendido
Os consumidores saberão que os dados referidos, extraídos do conjunto de dados corrente, não estão disponíveis ou apenas podem ser disponibilizados sob condições diferentes.
Possível Abordagem para Implementação
Dependendo do contexto da máquina e/ou das pessoas, existem várias maneiras de indicar indisponibilidade de dados. Os publicadores de dados podem publicar um documento em HTML – que dá uma explicação legível por pessoas para a indisponibilidade de dados. Da perspectiva da interface de aplicação de uma máquina, podem ser utilizados códigos de status HTTP apropriados, com mensagens personalizadas e legíveis por pessoas. Exemplos dos códigos de status incluem: 303 (veja outros, do inglês see other), 410 (removido permanentemente, do inglês permanently removed), 503 (serviço *fornecer dados* não disponível, do inglês service *providing data* unavailable).
Como Testar
Quando o conjunto de dados incluir referências a dados que não estejam mais disponíveis ou que não estejam disponíveis para todos os usuários, verifique se explicações sobre o que está faltando e instruções para obter acesso (se possível) são fornecidas. Verifique se um código de resposta HTTP legítimo é recebido na faixa de 400 ou 500 ao tentar obter dados indisponíveis.
Boa Prática 23: Disponibilizar dados por meio de uma API
Disponibilizar uma API para servir os dados caso você tenha recursos para tanto.
Porque
Uma APIoferece aos consumidores de seus dados maior flexibilidade e facilidade de processamento. Ela pode habilitar o uso de dados em tempo real, realizar filtragens a partir de solicitações e permite trabalhar com os dados em um nível atômico. Caso o seu conjunto de dados seja grande, frequentemente atualizado ou altamente complexo, é provável que uma API seja a melhor opção para publicar seus dados.
Resultado Pretendido
Os desenvolvedores terão acesso programático aos dados para usar em suas próprias aplicações, com os dados atualizados e sem exigir esforço por parte dos consumidores. As aplicações Web terão a capacidade de obter dados específicos consultando uma interface programática.
Possível Abordagem para implementação
Criar uma API é um pouco mais complexo do que publicar dados para download.Demanda algum conhecimento de como construir uma aplicação Web. No entanto, não é necessário construir uma a partir do zero. Caso uma plataforma de gerenciamento de dados seja utilizada, tal como a CKAN, você poderá habilitar uma API já existente. Muitas estruturas de desenvolvimento Web incluem suporte para APIs e também disponibilizam estruturas projetadas especificamente para a construção de APIs personalizadas.
Rails (Ruby), Django (Python) e Express (NodeJS) são alguns exemplos de estruturas de desenvolvimento Web que oferecem suporte para criação de APIs. Exemplos de estruturas API incluem Swagger, Apigility, Restify e Restlet.
Como Testar
Verifique se um cliente de teste pode simular chamadas e se a API responde de acordo com o previsto.
Boa Prática 24: Usar padrões Web como base para construção de APIs
Ao desenvolver APIs, utilizar um estilo arquitetônico baseado nas tecnologias da própria Web.
Porque
As APIs construídas com base nos padrões Web fortalecem a Web. Por exemplo, utilizar verbos HTTP (do inglês, HTTP verbs) como métodos e URLs que se orientam diretamente a recursos individuais, ajuda a evitar o acoplamento apertado entre solicitações e respostas, produzindo assim uma API de manutenção simples, e que pode ser facilmente compreendida e utilizada por muitos desenvolvedores. O fato de que a Web é apátrida pode ser um reforço para um escalonamento rápido de permissão, e o uso da hipermídia possibilita interações ricas com sua API.
Resultado Pretendido
Desenvolvedores com alguma experiência em APIs baseadas em padrões Web, como REST, terão um entendimento inicial de como utilizar a API. A manutenção da API será também mais fácil.
Possível Abordagem para implementação
REST (do inglês Representational State Transfer) [Fielding][Richardson] é um estilo arquitetônico que, quando usado em uma API, Web, beneficia-se da arquitetura da própria Web. Uma discussão completa sobre como criar uma API RESTful está além do escopo deste documento, porém existem muitos recursos e uma comunidade consolidada que pode auxiliar a iniciar este trabalho. Ademais, há muitas estruturas de desenvolvimento RESTful disponíveis. Caso você já esteja usando uma estrutura de desenvolvimento Web que suporte a construção de APIs REST, considere o uso desta. Caso contrário, considere uma estrutura somente de API que utilize REST.
Outro aspecto da implementação que deve ser considerado é fazer uma API, de hipermídia, que responda com links e também com dados. São os links que tornam a Web uma rede e APIs de dados podem ser mais úteis e utilizadas com a inclusão de links em suas respostas. Os links podem oferecer recursos adicionais, documentação e navegação. Mesmo para uma API que não atenda a todas as restrições do REST, retornar links nas respostas pode resultar em um serviço rico e com documentação própria.
Como Testar
Verifique se o serviço evita a utilização do http como um canal de chamadas destinadas a métodos personalizados, e verifique se os URLs não contêm nomes de métodos.
Boa Prática 25: Fornecer documentação completa para as APIs
Fornecer informações completas na Web sobre a API. Atualizar a documentação conforme características adicionadas ou modificações realizadas.
Porque
Os desenvolvedores são os principais consumidores de uma API e a documentação é a primeira indicação sobre a qualidade e utilidade da mesma. Quando a documentação da API é completa e fácil de compreender, os desenvolvedores provavelmente ficarão mais dispostos a continuar utilizando-a. Fornecer a documentação de forma abrangente em um único lugar permite que os desenvolvedores possam codificar com eficiência. Realçar as modificações proporciona aos usuários que aproveitem os novos recursos e ajustem seus próprios códigos, se necessário.
Resultado Pretendido
Os desenvolvedores serão capazes de obter informações detalhadas sobre cada chamada à API, inclusive os parâmetros suportados e quais se espera que retorne, como por exemplo, o conjunto completo das informações referentes à API. O conjunto de valores – como utilizá-la, aviso de modificações recentes, informações de contato e assim por diante – deve ser descrito e facilmente navegável na Web. Isto irá permitir também que as máquinas acessem a documentação da API de forma a auxiliar os desenvolvedores a construir um software cliente da API.
Possível Abordagem para Implementação
Uma referência típica de API fornece uma lista abrangente das chamadas que a API pode suportar, com a descrição do objetivo de cada uma, detalhando os parâmetros que esta permite, assim como quais retorna, e dando um ou mais exemplos de seu uso. Um registro interessante na documentação de API é fornecer um formulário no qual os desenvolvedores possam inserir chamadas específicas para testes, para ver o que a API retorna em seus casos de utilização. Já existem ferramentas disponíveis para criar este tipo de documentação de forma rápida, como Swagger (em inglês), io-docs (em inglês), OpenApis (em inglês), entre outras. É importante dizer que a API também deve ter documentação própria, de forma que as chamadas retornem informações úteis sobre erros e utilização. Os usuários da API devem poder entrar em contato com os mantenedores com perguntas, sugestões ou relatórios de erros.
A qualidade da documentação também está relacionada ao uso de feedback dos desenvolvedores. Tente obter feedbacks constantes de seus usuários sobre a documentação.
Como Testar
Verifique se todas as chamadas habilitadas por sua API estão descritas na documentação. Assegure-se de estar fornecendo detalhes sobre quais parâmetros são obrigatórios e quais são opcionais, e o que cada chamada retorna.
Verifique o Tempo para a Primeira Chamada Bem Sucedida, do inglês Time To First Successful Call (por exemplo, ser capaz de fazer um pedido com sucesso à API em poucos minutos aumentará as possibilidades do desenvolvedor continuar a usar a sua API).
Boa Prática 26: Evitar alterações que afetem o funcionamento de sua API
Evitar alterações em sua API que afetem o código do cliente e, quando houver evolução, informar seus desenvolvedores sobre quaisquer modificações feitas na API.
Porque
Quando desenvolvedores implementam um cliente à sua API,podem estar contando com características específicas que você incorporou à API, tais como o esquema ou o formato de uma resposta. Evitar modificações que afetam o funcionamento de sua API minimiza erros no código do cliente. Comunicar as modificações quando estas ocorrerem permite aos desenvolvedores beneficiarem-se de novos recursos e, no caso raro em que haja uma modificação que afete o funcionamento da API, tomem providências.
Resultado Pretendido
O código do desenvolvedor continuará funcionando. O desenvolvedor saberá das melhorias que você implementou e poderá utilizá-las. Modificações que afetem o funcionamento de sua API serão raras e, caso sejam necessárias, os desenvolvedores terão tempo e informação suficientes para ajustar seus códigos. Isto possibilitará que erros sejam evitados, aumentando a confiança. Modificações à API serão anunciadas no sítio de documentação da API.
Possível Abordagem para Implementação
Ao enriquecer sua API, concentre-se em adicionar novas chamadas ou novas opções em vez de modificar a maneira como as chamadas existentes operam. Os clientes existentes podem ignorar tais modificações e continuarão a funcionar.
Caso estiver usando um estilo RESTful de forma integral, você deve ser capaz de evitar modificações que afetem os desenvolvedores, mantendo URIs de recurso constantes e modificar somente elementos que seus usuários não codifiquem diretamente. Caso precise alterar seus dados de uma maneira não compatível com os pontos de extensão projetados inicialmente, será necessário um design completamente novo – o que significa modificações que afetam o funcionamento do código do cliente. Neste caso é melhor implementar as alterações como uma nova RESTAPI, com um URI de recurso diferente.
Se você está utilizando um estilo arquitetônico que não permite fazer alterações relativamente significantes, sem afetar o código do cliente, utilize o versionamento. Indique a versão no cabeçalho de resposta. Os números da versão devem estar refletidos em seus URIs ou nos cabeçalhos de solicitação de “aceite” (usando negociação do conteúdo). Ao utilizar o versionamento nos URIs inclua o número da versão mais à esquerda o possível. Mantenha a versão anterior disponível para os desenvolvedores cujos códigos ainda não foram adaptados à nova versão.
Para notificar aos usuários diretamente sobre as modificações, é uma boa ideia criar uma lista de discussão e incentivar os desenvolvedores a inscreverem-se. Por este meio, você poderá anunciar modificações e proporcionar também um bom mecanismo para receber feedbacks. Além disso, a lista permite que os usuários ajudem-se mutuamente.
Como Testar
Libere modificações inicialmente em uma versão de teste da sua API antes de inseri-las na versão de produção. Convide os desenvolvedores a testar suas aplicações na versão de teste e fornecer feedbacks.
O grupo de trabalho reconhece que não é realista assumir que todos os dados da Web estarão disponíveis sob demanda o tempo todo até um futuro indefinido. Por uma ampla gama de motivos, os publicadores provavelmente irão querer ou precisar remover dados da Web – aspecto que foge do escopo do presente trabalho para entrar na área dos arquivistas de dados. O que faz parte do escopo aqui, no entanto, é o que é deixado para trás – isto é, o que deve ser feito pelos publicadores para indicar quais dados foram removidos ou arquivados. Simplesmente deletar um recurso da Web é uma má prática. Nesta circunstância, dereferenciar o URI conduziria a um código de resposta HTTP 404, que simplesmente informa ao usuário que o recurso não foi encontrado – nada além disto. As Boas Práticas a seguir oferecem abordagens mais produtivas.
Boa Prática 27: Preservar identificadores
Ao remover dados da Web, preservar o identificador e fornecer informações sobre o recurso arquivado.
Porque
O dereferenciamento do URI é a interface primária para os dados na Web. Caso o dereferenciamento de um URI conduza ao infame código 404 (Não Encontrado), o usuário não saberá se a falta de disponibilidade é permanente ou temporária, planejada ou acidental. Caso o publicador ou um terceiro tenha arquivado o dado, é muito menos provável que aquela cópia arquivada possa ser encontrada se o URI esteja efetivamente inacessível.
Resultado Pretendido
O URI de um recurso irá sempre dereferenciar para o recurso ou redirecionar para informações a respeito.
Possível Abordagem para Implementação
Há dois cenários a considerar:
O recurso foi totalmente deletado e não está mais disponível através de nenhuma rota;
O recurso foi arquivado e está disponível somente por meio de uma solicitação ao arquivo.
No primeiro caso, o servidor deve ser configurado para responder com um código de Resposta HTTP 410 (Perdido, do inglês Gone) (em inglês). A partir da especificação:
A resposta 410 destina-se principalmente a auxiliar na tarefa de manutenção da Web, notificando o destinatário de que o recurso encontra-se intencionalmente indisponível e que os proprietários do servidor desejam que os links remotos para este recurso sejam removidos.
No segundo caso, em que os dados tenham sido arquivados, é mais apropriado redirecionar as solicitações para uma página Web que forneça informações sobre o arquivo no qual os dados estão armazenados, e como um usuário em potencial pode acessá-lo.
Em ambos os casos, o URI original continua identificando o recurso e apontando para informações úteis – mesmo que o dado já não se encontre diretamente disponível.
Como Testar
Garanta que a dereferência de um URI de um conjunto de dados que não esteja mais disponível retorne informações tanto sobre a situação atual quanto sobre a disponibilidade do conjunto de dados em questão – quer seja utilizando o código de resposta 410 ou o código 303, conforme o mais apropriado.
Boa Prática 28: Avaliar a cobertura do conjunto de dados
Avaliar a cobertura de um conjunto de dados antes de sua preservação.
Porque
Um bloco de dados na Web é, por definição, dependente do resto do diagrama global. Este contexto global influencia o significado da descrição dos recursos encontrados no conjunto de dados. A princípio, a preservação de um determinado conjunto de dados envolveria a conservação de todo o seu contexto. Ou seja, toda a Web de Dados.
Para arquivar, é necessário avaliar as conexões do descarte do conjunto de dados para recursos já preservados e para os vocabulários utilizados. Conjuntos de dados nos quais muito pouco dos vocabulários utilizados e/ou recursos apontados já se encontram preservados em algum lugar, devem ser assinalados como conjunto de dados em risco.
Resultado Pretendido
Os usuários poderão fazer uso dos dados arquivados por muito tempo.
Possível Abordagem para Implementação
Verifique se todos os recursos utilizados já se encontram preservados em algum lugar ou precisam ser fornecidos junto com o conjunto de dados cuja preservação está sendo considerada.
Como Testar
Não é possível determinar o que estará disponível em 50 anos, por exemplo. No entanto, pode-se verificar se um conjunto de dados arquivado depende unicamente de recursos e vocabulários externos de ampla utilização. Verifique se as dependências exclusivas ou pouco utilizadas estão preservadas como parte do arquivo.
Publicar material na Web viabiliza o compartilhamento de dados em grande escala para uma diversidade de públicos com diferentes níveis de conhecimento. Os publicadores de dados querem garantir que os dados publicados atendam às necessidades dos consumidores de dados e, para esta finalidade, o feedback do usuário é crucial. Feedbacks agregam benefícios tanto para publicadores como consumidores, ajudando os primeiros a melhorar a integridade dos dados publicados, assim como incentivando-os a publicar novos dados. O feedback permite aos consumidores de dados terem uma voz descrevendo experiências de uso (por exemplo, aplicações usando dados), preferências e necessidades. Quando possível, feedbacks também devem ser disponibilizados publicamente para que outros consumidores de dados possam examiná-los. Disponibilizar feedbacks publicamente permite aos usuários conscientizarem-se de outros consumidores de dados, incentiva um ambiente colaborativo e possibilita que suas experiências comunitárias, preocupações ou perguntas sejam sempre atendidas.
Da perspectiva da interface do usuário existem diversas maneiras para coletar feedbacks de consumidores de dados, incluindo o registro no sítio, formulários de contato, seleção de avaliações de qualidade, pesquisas e caixas de comentários. Sob a perspectiva de de uma máquina, o publicador de dados pode também registrar métricas sobre utilização de dados ou informações sobre aplicações específicas que utilizam os dados. feedbacks como estes estabelecem um canal de comunicação entre publicadores e consumidores de dados. feedbacks disponibilizados publicamente devem ser exibidos em um formato legível por pessoas.
Esta seção fornece algumas Boas Práticas a serem seguidas por publicadores de dados visando possibilitar que os consumidores deem feedbacks. Tais feedbacks podem servir para pessoas ou máquinas.
Boa Prática 29: Coletar feedback de consumidores de dados
Fornecer meios fáceis de se encontrar para que os consumidores deem feedback.
Porque
Receber feedbacks ajuda os publicadores a compreenderem as necessidades de seus consumidores de dados, além de auxiliá-los a melhorar a qualidade dos dados publicados. Também aumenta a confiança na medida em que demonstra aos consumidores que o publicador se importa e se preocupa em atender às suas necessidades. Especificar claramente um mecanismo de feedback remove a inconveniência para o consumidor de dados de ter que procurar uma maneira de fornecer feedbacks.
Resultado Pretendido
Os consumidores de dados poderão fornecer feedbacks e avaliações sobre os conjuntos de dados e suas distribuições.
Possível Abordagem para implementação
Forneça aos consumidores de dados um ou mais mecanismos para o envio de feedbacks, incluindo (mas não limitando a) um formulário de contato, botões para ranquear a qualidade de dados ou uma caixa de comentários. Para aproveitar ao máximo os feedbacks recebidos de consumidores, uma boa ideia é coletá-lo por meio de um sistema de rastreamento que captura cada item em uma base de dados, assim permitindo quantificação e análise. Outra boa ideia é a captura por tipo de item de feedbacks por exemplo, sua motivação (edição, classificação [avaliação], comentário ou questionamento), de maneira que cada item possa ser expresso utilizando o vocabulário Dataset Usage Vocabulary [VOCAB-DUV].
Como Testar
Verifique se pelo menos um mecanismo de feedback foi fornecido e se este pode ser facilmente encontrado por consumidores de dados
Boa Prática 30: Compartilhar o feedback disponível
Disponibilizar publicamente mecanismos de feedback de consumidor sobre conjuntos de dados e distribuições.
Porque
Ao compartilhar feedback com consumidores, os publicadores demonstram aos usuários que suas contribuições estão sendo levadas em conta, e podem evitar o envio de relatórios de erros duplicados. Compartilhar feedback também ajuda os consumidores a compreender quaisquer questões que possam afetar sua capacidade de utilizar dados, assim como estimula um sentimento de comunidade entre eles.
Resultado Pretendido
Os consumidores serão capazes de avaliar os tipos de erros que afetam o conjunto de dados, analisar as experiências de outros usuários com o mesmo, e assegurar-se de que o publicador está abordando ativamente os problemas conforme o necessário. Também poderão determinar se outros usuários já forneceram feedbacks semelhantes, poupando-os do trabalho de enviar relatórios desnecessários e evitando que os responsáveis tenham que lidar com duplicidade.
Possível Abordagem para implementação
O feedback pode ficar disponível como parte de uma página Web em HTML, mas também pode ser fornecido em um formato legível por máquinas utilizando o vocabulário Dataset Usage Vocabulary [VOCAB-DUV].
Como Testar
Verifique se qualquer feedback fornecido por consumidores de dados para um determinado conjunto de dados ou distribuição esteja publicamente disponível.
Enriquecimento de dados refere-se a um conjunto de processos que pode ser utilizado para aperfeiçoar, aprimorar ou outra forma de melhorar dados brutos ou dados previamente processados. Esta ideia e outros conceitos semelhantes contribuem para transformar os dados em um bem valioso para quase todas as empresas ou empreendimentos modernos. É um tema diverso em si, cujos detalhes vão além do escopo deste documento. No entanto, vale a pena notar que algumas destas técnicas devem ser abordadas com cuidado, pois limites éticos podem vir à tona. Na pesquisa científica, cuidados devem ser tomados para evitar que o enriquecimento distorça resultados ou conclusões estatísticas. No tocante a dados sobre pessoas, questões de privacidade podem surgir quando conjuntos de dados são combinados. Ou seja, enriquecer um conjunto de dados com outro, quando nenhum dos dois contém informações suficientes sobre qualquer indivíduo a ponto de identificá-lo, pode resultar em um conjunto de dados combinado que comprometa a privacidade. Além disso, estas técnicas podem ser realizadas em escala, o que por sua vez realça a necessidade de cautela.
Esta seção fornece algumas recomendações a serem seguidas por publicadores de dados com a finalidade de enriquecimento de dados.
Boa Prática 31: Enriquecer dados por meio da geração de novos dados
Enriqueça seus dados gerando novos dados, pois ao fazê-lo você estará aumentando o valor dos mesmos.
Porque
O enriquecimento pode acentuar consideravelmente a facilidade de processamento, especialmente no caso de dados não estruturados. Em algumas circunstâncias, dados faltantes podem ser adicionados e novas atribuições e mensurações podem ser acrescentadas a partir de dados brutos pré-existentes. Conjuntos de dados também podem ser enriquecidos por meio de coletas adicionais da mesma forma como os dados originais foram coletados, ou combinando dados originais com outros conjuntos de dados. Publicar conjuntos de dados mais completos pode aumentar a confiança, se feito de maneira adequada e ética. Derivar valores adicionais que sejam úteis economiza tempo para o usuário e incentiva mais tipos de reúsos. Há muitas técnicas inteligentes que podem ser utilizadas para enriquecer dados, tornando o conjunto de dados um bem ainda mais valioso.
Resultado Pretendido
Conjuntos de dados com dados faltantes serão melhorados por meio do preenchimento destes valores. A estrutura do conjunto de dados será verificada e a utilidade potencializada caso providências ou atributos relevantes sejam adicionados, porém somente se este incremento não distorcer os resultados analíticos, a significância ou a potência estatística.
Possível Abordagem para Implementação
As técnicas para o enriquecimento de dados são complexas e se estendem além do escopo deste documento, que visa somente indicar tais possibilidades.
A técnica de aprendizado de máquina pode ser facilmente aplicada para promover enriquecimento de dados. Os métodos incluem aqueles focados na categorização de dados, desambiguação, reconhecimento de entidades, análise de sentimentos e topificação, entre outros. Novos valores de dados podem ser criados tão simplesmente quanto executar um cálculo matemático por meio de colunas existentes. Outros exemplos incluem a inspeção visual para identificar recursos em dados espaciais e a referência cruzada com bancos de dados externos para informações demográficas. E por último, a geração de novos dados pode ser impulsionada por demanda, onde valores faltantes são calculados ou determinados de forma direta.
Valores gerados a partir de técnicas com base em inferência devem ser indicados como tal, e deve ser possível recuperar qualquer valor original substituído por enriquecimento.
Sempre que a licença permitir, o código usado para enriquecer os dados deve estar disponível junto com o conjunto de dados. Compartilhar tal código é particularmente importante para dados científicos.
A priorização das atividades de enriquecimento deve ser baseada no valor que o mesmo tem para o consumidor de dados, bem como pelo esforço necessário. O valor para o consumidor pode ser avaliado pela mensuração da demanda (por meio de pesquisas ou pelo rastreio de pedidos diretos. por exemplo). Documentar como você mensura a demanda pode tornar dar transparência ao valor agregado.
Caso você venha a enriquecer dados de outra pessoa, seria uma boa ideia oferecer estes enriquecimentos ao publicador original.
Como Testar
Verifique se não há valores faltantes no conjunto de dados ou campos adicionais prováveis de serem necessitados por outros, que poderiam ser facilmente fornecidos. Verifique se qualquer dado adicionado por técnicas de enriquecimento através de inferência esteja identificado como tal, e se quaisquer possíveis dados substituídos ainda estejam disponíveis.
Enriqueça seus dados apresentando-os em formas complementares e diretamente informativas, tais como visualizações, tabelas, aplicações Web ou resumos.
Porque
Dados publicados online destinam-se a passar informações para terceiros sobre seu tema. Porém, apenas publicar conjuntos de dados para download ou através de API delega ao consumidor o esforço de interpretá-los. A Web oferece oportunidades sem paralelos para a apresentação de dados de forma a permitir que os usuários aprendam e explorem sem ter que criar suas próprias ferramentas.
Resultado Pretendido
Visualizações complementares dos dados irão permitir que consumidores tenham uma percepção imediata dos mesmos por meio de visualizações de fácil entendimento.
Possível Abordagem para Implementação
Uma maneira muito simples de proporcionar entendimentos imediatos é publicar um resumo analítico em uma página HTML. Incluir dados que se somam em gráficos ou tabelas pode ajudar o usuário a explorar o resumo e entender com mais rapidez o sentido dos dados.
Caso você tenha meios de criar visualizações ou aplicações Web interativas que utilizem os dados, proporcionará aos seus consumidores uma capacidade ampliada de compreender e descobrir padrões em tais dados. Estas abordagens também demonstram a aptidão dos seus dados para o processamento e estimulam seu reúso.
Como Testar
Verifique se o conjunto de dados se encontra acompanhado de algum conteúdo adicional de interpretação que possa ser percebido sem o download dos dados ou a necessidade de invocar uma API.
Reutilizar dados é outra forma de publicar dados; é simplesmente republicá-los. Pode tomar a forma de uma combinação de dados existentes com outros conjuntos de dados, uma criação de aplicações ou visualizações Web, ou uma reempacotamento de dados em um novo formato, como uma tradução. Quem republica dados tem algumas responsabilidades que são exclusivas desta forma de publicação na Web. Este seção fornece recomendações que devem ser observadas ao republicar dados.
Boa Prática 33: Fornecer feedback para o publicador original
Informar ao publicador original quando você está promovendo o reúso de seus dados. Informe-o caso encontre um erro, ou tenha sugestões ou elogios a tecer.
Porque
Os publicadores geralmente querem saber se os dados que publicam têm sido úteis. Ademais, eles podem ser obrigados a relatar estatísticas de uso a fim de alocar recursos para atividades de publicação de dados. Ao informar como dos dados publicados foram usados, você estará ajudando os publicadores originais a justificar a aplicação de recursos no lançamento de dados. Fornecer feedback recompensa os publicadores por seus esforços e os ajuda diretamente a melhorar seu conjunto de dados para futuros usuários.
Resultado Pretendido
Uma melhor comunicação facilitará para os publicadores originais determinar como os dados que postaram estão sendo usados, o que por sua vez os ajuda a justificar a publicação dos dados. Eles também terão clareza sobre quais medidas podem adotar para melhorar seus dados. Isto conduz a mais e melhores dados para todos.
Possível Abordagem para Implementação
Quando iniciar a utilização de um conjunto de dados em um produto novo, faça uma nota com o endereço e contato dos publicadores, o URI do conjunto de dados que você utilizou, e a data em que os contatou. Isto pode ser feito em comentários dentro do seu código, onde o conjunto de dados é usado. Utilize os meios disponibilizados pelos publicadores para dar feedback. Caso a possibilidade de feedback não seja oferecida, procure esta informação de contato no sítio Web que hospeda os dados.
Como Testar
Verifique se você tem um registro de pelo menos um comunicado informando ao publicador sobre a utilização de tais dados.
Encontrar e seguir os requisitos de licença indicada pelo publicador original do conjunto de dados.
Porque
A licença fornece uma estrutura jurídica para utilizar o trabalho de outra pessoa. Ao respeitar os requisitos do publicador original, você promove relações amigáveis entre você e o publicador. Não é necessário preocupar-se com ações jurídicas caso respeite o que o publicador original deseja. Além disso, compreender a licença original ajudará a determinar qual licença escolher para sua reutilização.
Resultado Pretendido
Os publicadores de dados poderão confiar que seus trabalhos estarão sendo utilizados de acordo com as condições de licença, o que provavelmente os estimulará a continuar publicando dados. Quem republicar dados poderá definir a licença de seus trabalhos derivados de maneira adequada.
Possível Abordagem para Implementação
Leia a licença original e respeite seus requisitos. Caso este solicitar licença específico de trabalhos derivados, tome providências para que sua licença seja compatível com este requisito. Caso nenhuma licença seja fornecida, contate o publicador original e pergunte a ele qual é a licença aplicável.
Como Testar
Leia todo a licença original e certifique-se de que sua utilização dos dados não viola qualquer um de seus termos.
Boa Prática 35: Citar a publicação original do conjunto de dados
Reconhecer a fonte de seus dados nos metadados. Caso forneça uma interface de usuário, inclua a citação claramente na interface.
Porque
Dados só são úteis quando são confiáveis. Citar a fonte é o maior indicativo de confiança por dois motivos: em primeiro lugar, o usuário pode julgar a confiança em seus dados a partir da reputação da fonte e, em segundo, citar a fonte sugere que você mesmo é confiável como republicador de dados. Além de informar o usuário final, citar a fonte ajuda os publicadores dando crédito ao seu trabalho. Publicadores que disponibilizam dados na Web merecem reconhecimento e ficam mais propensos a continuar compartilhando seus dados caso percebam que estão sendo creditados. A citação também mantém a procedência e ainda ajuda outros a trabalhar com os dados.
Resultado Pretendido
Usuários finais poderão avaliar a confiança nos dados que estão visualizando e os esforços dos publicadores originais serão reconhecidos. Também será possível rastrear a procedência dos dados na Web até o publicador original.
Possível Abordagem para Implementação
A citação da fonte original pode ser apresentada em uma interface de usuário fornecendo o texto bibliográfico e um link operável.
Como Testar
Verifique se a fonte original de quaisquer dados reutilizados se encontra citada nos metadados fornecidos.
Verifique se há uma citação legível por pessoas claramente visível em qualquer interface de usuário.
O arquivamento de dados é um conjunto de práticas em torno do armazenamento e monitoramento do estado do material digital ao longo dos anos.
Estas tarefas são de responsabilidade de um Repositório Digital Confiável, do inglês Trusted Digital Repository (TDR), também chamado eventualmente de Serviço de Arquivamento de Longo Prazo, do inglês Long-Term Archive Service (LTA) (em inglês). Muitas vezes, tais serviços seguem o Sistema de Informação de Arquivos Abertos, do inglês Open Archival Information System [OAIS] que define o processo de arquivamento em termos de consumo, monitoramento e reutilização de dados.
Citação
Uma Citação pode ser direta e explícita (como uma lista de referências de um artigo de periódico), indireta (como, por exemplo, a citação a um documento mais recente do mesmo grupo de pesquisa sobre o mesmo assunto) ou implícita (como em citações artísticas, paródias ou em casos de plágio).
Define-se um conjunto de dados como uma coleção de dados, publicados ou curados por um único operador e disponíveis para acesso ou download em um ou mais formatos. Um conjunto de dados não tem que ser disponibilizado como arquivo para download.
Para os fins deste Grupo de Trabalho, um Consumidor de Dados é uma pessoa ou um grupo que acessa, usa, e potencialmente executa passos após o processamento dos dados.
De: Strong, Diane M., Yang W. Lee, e Richard Y. Wang. Data quality in context. Communications of the ACM 40.5 (1997): 103-110.
Dados Estruturados
Dados Estruturados referem-se a dados que estão em conformidade com um esquema fixo. Bancos de dados e planilhas relacionais são exemplos de dados estruturados.
Dados legíveis por máquinas
Dados legíveis por máquinas são dados em formato padronizado que podem ser lidos e processados automaticamente por um sistema computacional. Documentos tradicionais de editores de texto e formato de documento portátil (PDF) são facilmente lidos por pessoas, porém normalmente são complicados para interpretação e manipulação por máquinas. Formatos tais como XML, JSON, HDF5, RDF e CSV são formatos legíveis por máquinas.
Dados sensíveis são quaisquer dados ou metadados de uso limitado e/ou destinados a públicos restritos. Podem incluir dados pessoais, dados corporativos ou governamentais. Maus usos a dados sensíveis podem levar a danos a indivíduos ou organizações.
Distribuição
Uma distribuição representa um determinado formato disponível de um conjunto de dados. Cada conjunto de dados pode ser disponibilizado em diferentes formatos; estes podem representar formatos diferentes do conjunto de dados ou pontos diferentes de término. Exemplos de distribuições incluem um arquivo CSV para download, uma API ou um feed RSS.
Utiliza-se um fórum de feedback para coletar mensagens publicadas pelos consumidores sobre um assunto específico. Estas mensagens podem incluir respostas para outros consumidores. Registros temporais de data são associadas a cada mensagem e estas podem ser associadas a uma pessoa ou submetidas anonimamente.
Para compreender melhor porque uma anotação foi criada, um esquema conceitual SKOS, do inglês SKOS Concept Scheme [SKOS-PRIMER] é utilizado para mostrar anotações inter-relacionadas entre comunidades com diferenciações mais significativas do que uma simples árvore de classe e subclasse.
Formato de Arquivo
O Formato de Arquivo é uma maneira padronizada por meio da qual a informação é codificada para armazenamento em um arquivo de computador. Ele especifica como os bits são usados para codificar informação em um meio digital de armazenamento. Formatos de arquivos podem ser proprietários ou livres e também novos ou disponíveis.
Exemplos de formatos de arquivos incluem: texto simples (em uma codificação de caracteres especificada, idealmente UTF-8),Comma Separated Variable (CSV) [RFC4180], Portable Document Format [PDF], XML (em inglês), JSON [RFC4627], Turtle [Turtle] e HDF5 (em inglês).
Formato de Dados
O Formato de Dados é definido como uma convenção específica para a representação de dados, ou seja, a maneira como a informação é codificada e armazenada para uso em um sistema de computador, possivelmente restringida por um tipo de dados formal ou um conjunto de padrões.
Uma coleção de preferências internacionais, normalmente relacionadas a um idioma e a uma região geográfica que uma (determinada categoria) de usuários necessita. São geralmente identificadas por um identificador abreviado ou código, tal como uma etiqueta de idioma, que é indicada a partir do ambiente para vários processos de forma a obter um comportamento culturalmente afetado.
Um padrão técnico é uma norma ou requisito estabelecido a respeito de sistemas técnicos. Normalmente é um documento formal que estabelece critérios técnicos ou de engenharia padronizadas, métodos, processos e práticas. Em contraste, um costume, uma convenção, um produto de uma empresa, um padrão corporativo, etc., que se torna comumente aceito e dominante é frequentemente chamado de “padrão de fato”.
A Preservação de Dados é definida pela Alliance for Permanent Access Network (em inglês) como “os processos e operações para assegurar a sobrevivência técnica e intelectual de objetos através do tempo”. Isto faz parte de um processo de gerenciamento de dados com foco no planejamento da preservação e dos metadados (em inglês). Avaliar se vale a pena esforçar-se pela preservação depende do valor (futuro) dos dados, dos recursos disponíveis e da opinião da comunidade designada de stakeholders.
Procedência de dados
Procedência deriva do termo francês provenir (vir de), usado para descrever o processo de curadoria de objetos de arte quando são passados de proprietário para proprietário. De forma semelhante, a procedência de dados é um metadado que permite que os fornecedores de dados passem detalhes sobre o histórico de dados aos usuários.
Produtor de dados
O Produtor de Dados é uma pessoa ou um grupo responsável pela geração e manutenção de dados.
De: Strong, Diane M., Yang W. Lee, e Richard Y. Wang. Data quality in context. Communications of the ACM 40.5 (1997): 103-110.
Qualidade de dados
A qualidade de dados é geralmente definida como “aptidão para uso” para uma aplicação específica ou um caso de uso.
Quase em tempo real
A expressão “quase em tempo real” ou “praticamente em tempo real” usada em telecomunicações e computação refere-se ao atraso de tempo decorrente do processamento automatizado de dados ou pela transmissão em rede, entre a ocorrência de um evento e o uso dos dados processados, tal como para a finalidade de exibição ou feedback e controle. Por exemplo, uma exibição em quase tempo real mostra um evento ou situação como se esta existisse no momento corrente menos o tempo de processamento, como praticamente no tempo do evento ao vivo.
Um vocabulário é uma coletânea de “termos” para uma determinada finalidade. Os vocabulários podem variar desde os mais simples, tais como os frequentemente utilizados RDF Schema [RDF-SCHEMA], FOAF [FOAF] e Dublin Core [DCTERMS] até vocabulários complexos, com milhares de termos, como aqueles usados nos cuidados de saúde para descrever sintomas, doenças e tratamentos. Os vocabulários têm um papel importante nos Dados Conectados, especialmente no suporte à integração de dados. O uso deste termo sobrepõe-se à Ontologia.
O diagrama a seguir resume alguns dos principais desafios enfrentados ao publicar ou consumir dados na Web. Estes desafios foram identificados a partir do documento Requisitos e Casos de Uso das Boas Práticas para Dados na Web, do inglês Data on the Web Best Practices Use Cases & Requirements [DWBP-UCR] e, como apresentado no diagrama, são mencionados por uma ou mais Boas Práticas.
11. Benefícios das Boas Práticas
Esta seção não é normativa.
A lista abaixo descreve os principais benefícios da aplicação da recomendação DWBP. Cada benefício representa uma melhoria na maneira como os conjuntos de dados são disponibilizados na Web.
Compreensão: as pessoas terão um melhor entendimento sobre a estrutura e o significado dos dados, os metadados e a natureza do conjunto de dados.
Facilidade de Processamento: as máquinas serão capazes de processar e manipular automaticamente os dados dentro de um conjunto de dados.
Facilidade de Descoberta: as máquinas serão capazes de descobrir automaticamente um conjunto de dados ou dados dentro de um conjunto de dados.
Reúso: aumentarão as possibilidades de reutilização do conjunto de dados por diferentes grupos de consumidores de dados.
Confiança: a confiança que os clientes depositam no conjunto de dados se ampliará.
Capacidade de Conexão: será possível criar conexões entre os recursos de dados (conjuntos de dados e itens de dados).
Facilidade de Acesso: pessoas e máquinas serão capazes de acessar dados atualizados de várias maneiras.
Interoperabilidade: será mais fácil alcançar um consenso entre publicadores de dados e consumidores.
A tabela a seguir relaciona Boas Práticas e Benefícios
Os editores agradecem as contribuições feitas a este documento por todos os membros do grupo de trabalho. Especialmente o grande esforço realizado por Annette Greiner e os subsídios recebidos de Antoine Isaac, Eric Stephan e Phil Archer.
Este documento beneficiou-se da colaboração de muitos membros do Grupo de Trabalho em Dados Espaciais na Web, do inglês Spatial Data on the Web Working Group. Devemos agradecimentos especiais aos colegas Andrea Perego, Dan Brickley, Linda van den Brink e Jeremy Tandy.
Os editores gostariam também de agradecer pelos comentários recebidos de Addison Phillips, Adriano Machado, Adriano Veloso, Andreas Kuckartz, Augusto Herrmann, Bart van Leeuwen, Christophe Gueret, Erik Wilde, Giancarlo Guizzardi, Gisele Pappa, Gregg Kellogg, Herbert Van de Sompel, Ivan Herman, Leigh Dodds, Lewis John McGibbney, Makx Dekkers, Manuel Tomas Carrasco-Benitez, Maurino Andrea, Michel Dumontier, Nandana Mihindukulasooriya, Nathalia Sautchuk Patrício, Peter Winstanley, Renato Iannella, Steven Adler, Vagner Diniz, e Wagner Meira.
Os editores também querem agradecer os presidentes deste Grupo de Trabalho: Deirdre Lee, Hadley Beeman, Yaso Córdova e o contato administrativo Phil Archer.
A introdução foi reorganizada e levemente ampliada para deixar claro que a recomendação DWBP é um documento geral complementado de forma mais detalhada em áreas mais específicas.
Atributos adicionais foram incorporados aos diagramas SVG para aumentar sua acessibilidade.
O nome usado no exemplo em execução, John, foi trocado para Adrian por ser mais neutro no que se refere a gênero, considerando o idioma original dos nomes, inglês.
