Jump to Table of Contents Collapse Sidebar

Data on the Web Best Practices

Lead translating organization:
Núcleo de Informação e Coordenação do Ponto BR
Av. das Nações Unidas, 11.541, 7º andar
São Paulo, SP - Brasil, 04578-907
Sítio Web: https://www.nic.br
Coordinator of the translation: Beatriz Rossi Corrales (biacorrales@nic.br)

Tradução Autorizada em Português do Brasil

Publicada em 29 de Outubro de 2019

Esta versão:
https://www.w3c.br/traducoes/DWBP-pt-br/
Versão mais recente:
https://www.w3.org/Translations/DWBP-pt-br/
Versão original em inglês:
https://www.w3.org/TR/dwbp/
Errata:
https://www.w3c.br/traducoes/DWBPerrata-pt-br/
Organização coordenadora da tradução (LTO):
Núcleo de Informação e Coordenação do Ponto BR
Av. das Nações Unidas, 11.541, 7º andar
São Paulo, SP - Brasil 04578-907
Sítio Web: https://www.nic.br
Coordenadora da tradução: Beatriz Rossi Corrales (biacorrales@nic.br)
Parceiros na revisão da tradução:
https://lists.w3.org/Archives/Public/w3c-translators/2018JulSep/0031.html
Resumo dos comentários públicos da Candidata a Tradução Autorizada:
https://lists.w3.org/Archives/Public/public-auth-trans-pt-br/2019Oct/0013.html

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.

Resumo

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).

O Grupo de Trabalho Boas Práticas para Dados na Web (em inglês) foi criado (em inglês) para desenvolver o ecossistema de dados abertos de maneira a facilitar uma comunicação mais qualificada entre os desenvolvedores e os publicadores; para fortalecer a confiança nos dados entre os desenvolvedores, seja qual for a tecnologia que estes escolham utilizar, potencializando inovações genuínas. Este documento de boas práticas é complementado pelos vocabulários Qualidade de Dados, do inglês Data Quality Vocabulary (em inglês) e Uso de Conjunto de Dados, do inglês Dataset Usage Vocabulary (em inglês).

Este documento foi publicado pelo Grupo de Trabalho Boas Práticas para Dados na Web (em inglês) como uma Recomendação. Caso haja interesse em enviar comentários sobre este documento favor enviá-los para public-dwbp-comments@w3.org (assinatura, arquivos, em inglês). Todos os comentários são bem-vindos.

Favor consultar o relatório de implementação (em inglês) do Grupo de Trabalho.

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.

Este documento foi produzido por um grupo operando em conformidade com a Política de Patentes do W3C de 5 de Fevereiro de 2004 (em inglês). O W3C mantém uma lista pública de patentes divulgadas (em inglês) relacionadas com os resultados do grupo, e tal página também contém as instruções para divulgação de patentes. Alguém que tenha conhecimento de uma patente que acredite conter Reivindicações Essenciais (em inglês) deverá divulgar as informações de acordo com a seção 6 da Política de Patentes do W3C (em inglês).

Este documento é regido pelo Documento Processual de 1º de Setembro de 2015 do W3C (em inglês).

1. Introdução

Esta seção não é normativa.

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:

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.

Publicação de dados na Web Conjunto de dados Metadados possui Distribuição 1 Conteúdo Metadados possui Distribuição n Conteúdo Metadados usa Princípios Arquiteturais Web usa Vocabulários 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.

Espaços de nome utilizados neste documento
Prefixo Espaço de Nome IRI Descrição
dcat https://www.w3.org/ns/dcat# Data Catalog Vocabulary (DCAT)
dct https://purl.org/dc/terms/ Dublin Core Metadata Initiative (DCMI)
dqv https://www.w3.org/ns/dqv# DWBP Data Quality Vocabulary (DQV)
duv https://www.w3.org/ns/duv# DWBP Dataset Usage Vocabulary (DUV)
foaf https://xmlns.com/foaf/0.1/ Friend of a Friend Vocabulary (FOAF)
oa https://www.w3.org/ns/oa# Web Annotation Ontology
owl https://www.w3.org/2002/07/owl# Web Ontology Language (OWL)
pav https://pav-ontology.github.io/pav/ Provenance, Authoring and versioning Ontology (PAV)
prov https://www.w3.org/ns/prov# Provenance Ontology (PROV)
rdf https://www.w3.org/1999/02/22-rdf-syntax-ns# Resource Description Framework (RDF)
rdfs https://www.w3.org/2000/01/rdf-schema# RDF Schema (RDFS)
skos https://www.w3.org/2004/02/skos/core# Simple Knowledge Organization System (SKOS)

6. Modelo de Boas Práticas

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.
  • Reuse
  • Comprehension
  • Linkability
  • Discoverability
  • Trust
  • Access
  • Interoperability
  • Processability

7. Sumário de Boas Práticas

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.

Evidências

Requisitos Relevantes: R-MetadataAvailable (em inglês), R-MetadataDocum (em inglês), R-MetadataMachineRead (em inglês)

Benefícios

  • Reuse
  • Comprehension
  • Discoverability
  • Processability

Boa Prática 2: Fornecer metadados descritivos

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.

Evidência

Requisitos Relevantes: R-MetadataAvailable (em inglês), R-MetadataMachineRead (em inglês), R-MetadataStandardized (em inglês)

Benefícios

  • Reuse
  • Comprehension
  • Discoverability

Boa Prática 3: Fornecer metadados estruturais

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:

Como Testar

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.

Evidências

Requisitos Relevantes: R-MetadataAvailable (em inglês)

Benefícios

  • Reuse
  • Comprehension
  • Processability

8.3 Licença de Dados

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:

Também existe uma série de linguagens legíveis por máquinas que expressam direitos de propriedade intelectual, tais como:

  • A Creative Commons Rights Expression Language [CCREL]
  • A Open Digital Rights Language [ODRL-model]
  • A Open Data Rights Statement Vocabulary [ODRS]

Como Testar

Verifique se os metadados do conjunto de dados incluem as informações de licença de dados em um formato legível por pessoas.

Verifique se um agente de software pode detectar ou descobrir de forma automática a licença do conjunto de dados.

Evidência

Casos de uso relevantes: R-LicenseAvailable (em inglês), R-MetadataMachineRead (em inglês), R-LicenseLiability (em inglês)

Benefícios

  • Reuse
  • Trust

8.4 Procedência de Dados

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.

Evidência

Requisitos Relevantes: R-ProvAvailable (em inglês), R-MetadataAvailable (em inglês)

Benefícios

  • Reuse
  • Comprehension
  • Trust

8.5 Qualidade 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.

Evidência

Requisitos Relevantes: R-QualityMetrics (em inglês), R-DataMissingIncomplete (em inglês), R-QualityOpinions (em inglês)

Benefícios

  • Reuse
  • Trust

8.6 Versionamento 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.

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.

Evidência

Requisitos Relevantes: R-DataVersion (em inglês)

Benefícios

  • Reuse
  • Trust

Boa Prática 8: Fornecer o histórico de versão

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.

Evidência

Requisitos Relevantes: R-DataVersion (em inglês)

Benefícios

  • Reuse
  • Trust

8.7 Identificadores de Dados

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:

  1. 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.
  2. 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.
  3. 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).
  4. Um URI pode redirecionar-se a outro.
  5. 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ó.

Evidência

Requisitos Relevantes: R-UniqueIdentifier (em inglês), R-Citable (em inglês)

Benefícios

  • Reuse
  • Linkability
  • Discoverability
  • Interoperability

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.

Evidência

Requisitos Relevantes: R-UniqueIdentifier (em inglês)

Benefícios

  • Reuse
  • Linkability
  • Discoverability
  • Interoperability

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.

Evidência

Requisitos Relevantes: R-UniqueIdentifier (em inglês), R-Citable (em inglês)

Benefícios

  • Reuse
  • Discoverability
  • Trust

8.8 Formatos de Dados

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.

Evidência

Requisitos Relevantes: R-FormatMachineRead (em inglês), R-FormatStandardized (em inglês), R-FormatOpen (em inglês)

Benefícios

  • Reuse
  • Processability

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:

"price" {
    "value": 2000.00,
    "currency": "EUR"
}
…

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.

Evidência

Requisitos Relevantes: R-FormatLocalize (em inglês), R-MetadataAvailable (em inglês), R-GeographicalContext (em inglês), R-FormatMachineRead (em inglês)

Benefícios:

  • Reuse
  • Comprehension

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.

Evidência

Requisitos Relevantes: R-FormatMultiple (em inglês)

Benefícios

  • Reuse
  • Processability

8.9 Vocabulários 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.

Evidência

Requisitos Relevantes: R-MetadataStandardize (em inglês), R-MetadataDocum (em inglês), R-QualityComparable (em inglês), R-VocabOpen (em inglês), R-VocabReference (em inglês)

Benefícios

  • Reuse
  • Processability
  • Comprehension
  • Trust
  • Interoperability

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 public-vocabs@w3.org [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.

Evidência

Requisitos Relevantes: R-VocabReference (em inglês), R-QualityComparable (em inglês)

Benefícios

  • Reuse
  • Comprehension
  • Interoperability

8.10 Acesso a Dados

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.

Evidência

Requisitos Relevantes: R-AccessBulk (em inglês)

Benefícios

  • Reuse
  • Access

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.

Evidência

Requisitos Relevantes: R-Citable (em inglês), R-GranularityLevels (em inglês), R-UniqueIdentifier (em inglês), R-AccessRealTime (em inglês)

Benefícios

  • Reuse
  • Linkability
  • Access
  • Processability

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.

Evidência

Requisitos Relevantes: R-FormatMachineRead (em inglês), R-FormatMultiple (em inglês)

Benefícios

  • Reuse
  • Access

Boa Prática 20: Fornecer acesso em tempo real

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.

Evidência

Requisitos Relevantes: R-AccessRealTime (em inglês)

Benefícios

  • Reuse
  • Access

Boa Prática 21: Fornecer dados atualizados

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.

Evidência

Requisitos Relevantes: R-AccessUptodate (em inglês)

Benefícios

  • Reuse
  • Access

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.

Evidência

Requisitos Relevantes: R-AccessLevel (em inglês), R-SensitivePrivacy (em inglês), R-SensitiveSecurity (em inglês)

Benefícios

  • Reuse
  • Trust

8.10.1 APIs de Acesso a Dados

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.

Evidência

Requisitos Relevantes: R-AccessRealTime (em inglês), R-AccessUpToDate (em inglês)

Benefícios
  • Reuse
  • Processability
  • Interoperability
  • Access

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.

Evidência

Requisitos Relevantes: R-APIDocumented (em inglês), R-UniqueIdentifier (em inglês)

Benefícios
  • Reuse
  • Linkability
  • Interoperability
  • Discoverability
  • Access
  • Processability

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).

Evidência

Requisitos Relevantes: R-APIDocumented (em inglês)

Benefícios
  • Reuse
  • Trust

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.

Evidência

Requisitos Relevantes: R-PersistentIdentification (em inglês), R-APIDocumented (em inglês)

Benefícios
  • Trust
  • Interoperability

8.11 Preservação de Dados

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:

  1. O recurso foi totalmente deletado e não está mais disponível através de nenhuma rota;
  2. 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.

Evidência

Requisitos Relevantes: R-AccessLevel (em inglês), R-PersistentIdentification (em inglês)

Benefícios

  • Reuse
  • Trust

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.

Evidências

Requisitos Relevantes: R-VocabReference (em inglês)

Benefícios

  • Reuse
  • Trust

8.12 Feedback

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

Evidência

Requisitos Relevantes: R-UsageFeedback (em inglês), R-QualityOpinions (em inglês)

Benefícios

  • Reuse
  • Comprehension
  • Trust

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.

Evidência

Requisitos Relevantes: R-UsageFeedback (em inglês), R-QualityOpinions (em inglês)

Benefícios

  • Reuse
  • Trust

8.13 Enriquecimento de Dados

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.

Evidência

Requisitos Relevantes: R-DataEnrichment (em inglês), R-FormatMachineRead (em inglês), R-ProvAvailable (em inglês)

Benefícios

  • Reuse
  • Comprehension
  • Trust
  • Processability

Boa Prática 32: Fornecer visualizações complementares

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.

Evidência

Requisitos Relevantes: R-DataEnrichment (em inglês)

Benefícios

  • Reuse
  • Comprehension
  • Access
  • Trust

8.14 Republicação de Dados

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.

Evidência

Requisitos Relevantes: R-TrackDataUsage (em inglês), R-UsageFeedback (em inglês), R-QualityOpinions (em inglês)

Benefícios

  • Reuse
  • Interoperability
  • Trust

Boa Prática 34: Obedecer os termos de licença

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.

Evidência

Requisitos Relevantes: R-LicenseAvailable (em inglês), R-LicenseLiability (em inglês),

Benefícios

  • Reuse
  • Trust

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.

Evidência:

Requisitos Relevantes: R-Citable (em inglês), R-ProvAvailable (em inglês), R-MetadataAvailable (em inglês), R-TrackDataUsage (em inglês)

Benefícios

  • Reuse
  • Discoverability
  • Trust

9. Glossário

Esta seção não é normativa.

Arquivamento de dados

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).

De: CiTO, the Citation Typing Ontology (em inglês).

Conjunto de dados

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.

De: Data Catalog Vocabulary (DCAT) (em inglês) [VOCAB-DCAT]

Consumidor de Dados

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.

Adaptado da Wikipedia (em inglês).

Dados sensíveis

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.

De: Data Catalog Vocabulary (DCAT) (em inglês) [VOCAB-DCAT]

Feedback

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.

De: Semantically-Interlinked Online Communities (SIOC) (em inglês) e Annotation Model [Annotation-Model]

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.

De: Digital Humanities Curation Guide (em inglês)

Licença

Uma licença é um documento jurídico que concede permissão oficial para fazer algo com dados a que se está associado.

De: DCTERMS [DCTERMS]

Localidade

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.

De: Language Tags and Locale Identifiers for the World Wide Web (em inglês) [LTLI].

Padrão

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”.

De: Wikipedia (em inglês)

Preservação de dados

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.

De: Wikipedia (em inglês)

Vocabulário

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.

De: Linked Data Glossary (em inglês)

10. Desafios de Dados na Web

Esta seção não é normativa

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.

Desafios de Dados na Web Desafios de Dados na Web Metadados Como eu forneço medatados para pessoas & máquinas? Fornecer metadados Fornecer metadados descritivos Fornecer metadados estruturais Licença de Dados Como forneço & restrinjo o acesso? Fornecer informações sobre a licença de dados Proveniência & Qualidade Como posso aumentar a confiança? Fornecer informações de proveniência dos dados Fornecer informações de qualidade dos dados Versionamento de Dados Como posso rastrear versões & histórico de versões? Fornecer indicador de versão Fornecer o histórico de versão Identificadores de Dados Como posso identificar conjuntos de dados & distribuições? Usar URIs persistentes como identificadores de conjuntos de dados Usar URIs persistentes como identificadores dentro de conjuntos de dados Atribuir URIs para as versões dos conjuntos de dados e séries Formato de Dados Quais formatos de dados devo usar? Usar formatos de dados padronizados e legíveis por máquinas Usar representações de dados que sejam independentes de localidade (locale neutral) Fornecer dados em vários formatos Vocabulário de Dados Como melhorar a interoperabildiade do dado? Reutilizar vocabulários, dando preferencia aos padronizados Escolher o nível de formalização adequado Acesso a Dados Como posso fornecer acesso ao dado? Fornecer download em massa (bulk download) Fornecer subconjuntos para conjuntos de dados grandes Usar negociação de conteúdo para servir os dados disponíveis em vários formatos Fornecer acesso em tempo real Fornecer dados atualizados Fornecer uma explicação para os dados que não estão disponíveis Tornar os dados disponíveis por meio de uma API Usar padrões Web como base para construção de APIs Fornecer documentação completa para as APIs Evitar alterações que afetem o funcionamento de sua API Preservação de Dados Como os dados podem ser arquivados? Preservar identificadores Avaliar a cobertura do conjunto de dados Feedback Como posso engajar usuários? Coletar feedback dos consumidores de dados Compartilhar o feedback disponível Enriquecimento de Dados Como posso agregar valor ao dado? Enriquecer dados por meio da geração de novos dados Fornecer visualizações complementares Republicação de Dados Como posso reutilizar dados responsavelmente? Fornecer feedback para o publicador original Obedecer os termos de licença Citar a publicação original do conjunto de dados

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.

A tabela a seguir relaciona Boas Práticas e Benefícios

Boas Práticas e Benefícios
Boa Prática Benefícios
Fornecer metadados
  • Reuse
  • Comprehension
  • Discoverability
  • Processability
Fornecer metadados descritivos
  • Reuse
  • Comprehension
  • Discoverability
Fornecer metadados estruturais
  • Reuse
  • Comprehension
  • Processability
Fornecer informações sobre a licença de dados
  • Reuse
  • Trust
Fornecer informações de procedência dos dados
  • Reuse
  • Comprehension
  • Trust
Fornecer informações de qualidade de dados
  • Reuse
  • Trust
Fornecer indicador de versão
  • Reuse
  • Trust
Fornecer o histórico de versão
  • Reuse
  • Trust
Usar URIs persistentes como identificadores de conjuntos de dados
  • Reuse
  • Linkability
  • Interoperability
Usar URIs persistentes como identificadores dentro de conjuntos de dados
  • Reuse
  • Linkability
  • Discoverability
  • Interoperability
Atribuir URIs para as versões dos conjuntos de dados e séries
  • Reuse
  • Discoverability
  • Trust
Usar formatos de dados padronizados legíveis por máquinas
  • Reuse
  • Processability
Usar representações de dados que sejam independentes de localidade (locale neutral)
  • Reuse
  • Comprehension
Fornecer dados em formatos múltiplos
  • Reuse
  • Processability
Reutilizar vocabulários, dando preferência aos padronizados
  • Reuse
  • Processability
  • Comprehension
  • Trust
  • Interoperability
Escolher o nível de formalização adequado
  • Reuse
  • Comprehension
  • Interoperability
Fornecer download em massa (bulk download)
  • Reuse
  • Access
Fornecer subconjuntos para conjuntos de dados extensos
  • Reuse
  • Linkability
  • Access
  • Processability
Usar negociação de conteúdo para disponibilizar dados em formatos múltiplos
  • Reuse
  • Access
Fornecer acesso em tempo real
  • Reuse
  • Access
Fornecer dados atualizados
  • Reuse
  • Access
Fornecer uma explicação para os dados que não estão disponíveis
  • Reuse
  • Trust
Disponibilizar dados por meio de uma API
  • Reuse
  • Processability
  • Interoperability
  • Access
Usar padrões Web como base para construção de APIs
  • Reuse
  • Linkability
  • Discoverability
  • Access
  • Processability
Fornecer documentação completa para as APIs
  • Reuse
  • Trust
Evitar alterações que afetem o funcionamento de sua API
  • Trust
  • Interoperability
Preservar identificadores
  • Reuse
  • Trust
Avaliar a cobertura do conjunto de dados
  • Reuse
  • Trust
Coletar feedback de consumidores de dados
  • Reuse
  • Comprehension
  • Trust
Compartilhar o feedback disponível
  • Reuse
  • Trust
Enriquecer dados por meio da geração de novos dados
  • Reuse
  • Comprehension
  • Trust
  • Processability
Fornecer visualizações complementares
  • Reuse
  • Comprehension
  • Access
  • Trust
Fornecer feedback para o publicador original
  • Reuse
  • Interoperability
  • Trust
Obedecer os termos de licença
  • Reuse
  • Trust
Citar a publicação original do conjunto de dados
  • Reuse
  • Discoverability
  • Trust

A figura abaixo demonstra os benefícios que os publicadores de dados obterão ao optar pela adoção das Boas Práticas.

REÚSO

Todas as Boas Práticas

12. Requisitos de Casos de Uso x Boas Práticas

Esta seção não é normativa

Requirements x Best Practices
Requisitos Boas Práticas
R-MetadataAvailable

Fornecer metadados

Fornecer metadados descritivos

Fornecer metadados estruturais

Fornecer informações de procedência dos dados

Usar representações de dados que sejam independentes de localidade (locale neutral)

Citar a publicação original do conjunto de dados

R-MetadataDocum

Fornecer metadados

Reutilizar vocabulários, dando preferência aos padronizados

R-MetadataMachineRead

Fornecer metadados

Fornecer metadados descritivos

Fornecer informações sobre a licença de dados

R-MetadataStandardized

Fornecer metadados descritivos

Reutilizar vocabulários, dando preferência aos padronizados

R-LicenseAvailable

Fornecer informações sobre a licença de dados

Obedecer os termos de licença

R-LicenseLiability

Fornecer informações sobre a licença de dados

Obedecer os termos de licença

R-ProvAvailable

Fornecer informações de procedência dos dados

Enriquecer dados por meio da geração de novos dados

Citar a publicação original do conjunto de dados

R-QualityMetrics

Fornecer informações de qualidade de dados

R-DataMissingIncomplete

Fornecer informações de qualidade de dados

R-QualityOpinions

Fornecer informações de qualidade de dados

Coletar feedback de consumidores de dados

Compartilhar o feedback disponível

Fornecer feedback para o publicador original

R-DataVersion

Fornecer indicador de versão

Fornecer o histórico de versão

R-UniqueIdentifier

Usar URIs persistentes como identificadores de conjuntos de dados

Usar URIs persistentes como identificadores dentro de conjuntos de dados

Atribuir URIs para as versões dos conjuntos de dados e séries

Fornecer subconjuntos para conjuntos de dados extensos

Usar padrões Web como base para construção de APIs

R-Citable

Usar URIs persistentes como identificadores de conjuntos de dados

Atribuir URIs para as versões dos conjuntos de dados e séries

Fornecer subconjuntos para conjuntos de dados extensos

Citar a publicação original do conjunto de dados

R-FormatMachineRead

Usar formatos de dados padronizados legíveis por máquinas

Usar negociação de conteúdo para disponibilizar dados em formatos múltiplos

Enriquecer dados por meio da geração de novos dados

R-FormatStandardized

Usar formatos de dados padronizados legíveis por máquinas

R-FormatOpen

Usar formatos de dados padronizados legíveis por máquinas

R-FormatLocalize

Usar representações de dados que sejam independentes de localidade (locale neutral)

R-GeographicalContext

Usar representações de dados que sejam independentes de localidade (locale neutral)

R-FormatMultiple

Fornecer dados em formatos múltiplos

Usar negociação de conteúdo para disponibilizar dados em formatos múltiplos

R-QualityComparable

Reutilizar vocabulários, dando preferência aos padronizados

Escolher o nível de formalização adequado

R-VocabOpen

Reutilizar vocabulários, dando preferência aos padronizados

R-VocabReference

Reutilizar vocabulários, dando preferência aos padronizados

Escolher o nível de formalização adequado

Avaliar a cobertura do conjunto de dados

R-AccessBulk

Fornecer download em massa (bulk download)

R-GranularityLevels

Fornecer subconjuntos para conjuntos de dados extensos

R-AccessRealTime

Fornecer subconjuntos para conjuntos de dados extensos

Fornecer acesso em tempo real

Disponibilizar dados por meio de uma API

R-AccessUpToDate

Fornecer dados atualizados

Disponibilizar dados por meio de uma API

R-AccessLevel

Fornecer uma explicação para os dados que não estão disponíveis

Preservar identificadores

R-SensitivePrivacy

Fornecer uma explicação para os dados que não estão disponíveis

R-SensitiveSecurity

Fornecer uma explicação para os dados que não estão disponíveis

R-APIDocumented

Usar padrões Web como base para construção de APIs

Fornecer documentação completa para as APIs

Evitar alterações que afetem o funcionamento de sua API

R-PersistentIdentification

Evitar alterações que afetem o funcionamento de sua API

Preservar identificadores

R-UsageFeedback

Coletar feedback de consumidores de dados

Compartilhar o feedback disponível

Fornecer feedback para o publicador original

R-DataEnrichment

Enriquecer dados por meio da geração de novos dados

Fornecer visualizações complementares

R-TrackDataUsage

Fornecer feedback para o publicador original

Citar a publicação original do conjunto de dados

A. Agradecimentos

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.

B. Histórico de Modificações

Modificações realizadas desde a versão anterior (em inglês):

C. Referências

C.1 Referências Informativas

[Annotation-Model]
Robert Sanderson; Paolo Ciccarese; Benjamin Young. W3C. Web Annotation Data Model (em inglês). 17 de Janeiro de 2017. W3C Proposed Recommendation. URL: https://www.w3.org/TR/annotation-model/ (em inglês)
[BCP47]
A. Phillips; M. Davis. IETF. Tags for Identifying Languages (em inglês). Setembro de 2009. IETF Best Current Practice. URL: https://tools.ietf.org/html/bcp47 (em inglês)
[BNF]
Bibliothèque nationale de France. Reference information about authors, works, topics (em inglês). URL: https://data.bnf.fr/ (em inglês)
[CCREL]
Hal Abelson; Ben Adida; Mike Linksvayer; Nathan Yergler. W3C/Creative Commons. ccREL: The Creative Commons Rights Expression Language (em inglês). 1 de Maio de 2008. W3C Member Submission. URL: https://www.w3.org/Submission/ccREL/ (em inglês)
[CLDR]
Unicode Consortium. Unicode Common Locale Data Repository (em inglês). URL: https://cldr.unicode.org/ (em inglês)
[DCTERMS]
Dublin Core metadata initiative. DCMI Metadata Terms (em inglês). 14 de Junho de 2012. DCMI Recommendation. URL: https://dublincore.org/documents/dcmi-terms/ (em inglês)
[DWBP-UCR]
Deirdre Lee; Bernadette Farias Loscio; Phil Archer. W3C. Data on the Web Best Practices Use Cases & Requirements (em inglês). 24 de Fevereiro de 2015. W3C Note. URL: https://www.w3.org/TR/dwbp-ucr/ (em inglês)
[FOAF]
Dan Brickley; Libby Miller. FOAF project. FOAF Vocabulary Specification 0.99 (Paddington Edition) (em inglês). 14 de Janeiro de 2014. URL: http://xmlns.com/foaf/spec/ (em inglês)
[Fielding]
Roy Thomas Fielding. University of California, Irvine. Representational State Transfer (REST), Chapter 5 of Architectural Styles and the Design of Network-based Software Architectures (em inglês). 2000. URL: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm (em inglês)
[GS1]
Mark Harrison; Ken Traub. GS1. SmartSearch Implementation Guideline (em inglês). Novembro de 2015. URL: https://www.gs1.org/gs1-smartsearch/guideline/gtin-web-implementation-guideline (em inglês)
[GTFS]
Pieter Colpaert; Andrew Byrd. General Transit Feed Specification (em inglês). URL: http://vocab.gtfs.org/gtfs.ttl# (em inglês)
[HTML-RDFA]
Manu Sporny. W3C. HTML+RDFa 1.1 - Second Edition (em inglês). 17 de Março de 2015. W3C Recommendation. URL: https://www.w3.org/TR/html-rdfa/ (em inglês)
[ISO-25964]
Stella Dextre Clarke et al. ISO/NISO. ISO 25964 – the international standard for thesauri and interoperability with other vocabularies (em inglês). URL: https://www.niso.org/schemas/iso25964/ (em inglês)
[ISO639-1-LOC]
Library of Congress. Ontology for ISO 639-1 Languages (em inglês). URL: https://id.loc.gov/ontologies/iso639-1_Languages (em inglês)
[JSON-LD]
Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. JSON-LD 1.0 (em inglês). 16 de Janeiro de 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/ (em inglês)
[LD-BP]
Bernadette Hyland; Ghislain Auguste Atemezing; Boris Villazón-Terrazas. W3C. Best Practices for Publishing Linked Data (em inglês). 9 de Janeiro de 2014. W3C Note. URL: https://www.w3.org/TR/ld-bp/ (em inglês)
[LODC]
Max Schmachtenberg; Christian Bizer; Anja Jentzsch; Richard Cyganiak. The Linking Open Data Cloud Diagram (em inglês). URL: https://lod-cloud.net/ (em inglês)
[LTLI]
Felix Sasaki; Addison Phillips. W3C. Language Tags and Locale Identifiers for the World Wide Web (em inglês). 23 de Abril de 2015. W3C Working Draft. URL: https://www.w3.org/TR/ltli/ (em inglês)
[Navathe]
Ramez Elmasri; Shamkant B. Navathe. Addison Wesley. Fundamentals of Database Systems. 2010.
[OAIS]
ISO/TC 20/SC 13. ISO. Space data and information transfer systems -- Open archival information system (OAIS) -- Reference model (em inglês). 21 de Agosto de 2012. ISO Standard. URL: https://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=57284 (em inglês)
[ODB]
World Wide Web Foundation. Open Data Barometer (em inglês). URL: http://opendatabarometer.org/ (em inglês)
[ODRL-model]
Renato Iannella; Serena Villata. W3C. ODRL Information Model (em inglês). 21 de Julho de 2016. W3C Working Draft. URL: https://www.w3.org/TR/odrl-model/ (em inglês)
[ODRS]
Leigh Dodds. The Open Data Institute. Open Data Rights Statement Vocabulary (em inglês). 29 de Julho de 2013. URL: https://schema.theodi.org/odrs/ (em inglês)
[OKFN-INDEX]
Open Knowledge Foundation. Global Open Data Index (em inglês). URL: https://index.okfn.org/ (em inglês)
[OWL2-OVERVIEW]
W3C OWL Working Group. W3C. OWL 2 Web Ontology Language Document Overview (Second Edition) (em inglês). 11 de Dezembro de 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-overview/ (em inglês)
[OWL2-PROFILES]
Boris Motik; Bernardo Cuenca Grau; Ian Horrocks; Zhe Wu; Achille Fokoue. W3C. OWL 2 Web Ontology Language Profiles (Second Edition) (em inglês). 11 de Dezembro de 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-profiles/ (em inglês)
[OWL2-QUICK-REFERENCE]
Jie Bao; Elisa Kendall; Deborah McGuinness; Peter Patel-Schneider. W3C. OWL 2 Web Ontology Language Quick Reference Guide (Second Edition) (em inglês). 11 de Dezembro de 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-quick-reference/ (em inglês)
[PAV]
Paolo Ciccarese; Stian Soiland-Reyes. PAV - Provenance, Authoring and Versioning (em inglês). 28 de Agosto de 2014. URL: https://purl.org/pav/ (em inglês)
[PDF]
Document management — Portable document format — Part 1: PDF (em inglês). ISO.
[PROV-O]
Timothy Lebo; Satya Sahoo; Deborah McGuinness. W3C. PROV-O: The PROV Ontology (em inglês). 30 de Abril de 2013. W3C Recommendation. URL: https://www.w3.org/TR/prov-o/ (em inglês)
[PROV-Overview]
Paul Groth; Luc Moreau. W3C. PROV-Overview (em inglês). 30 de Abril de 2013. W3C Note. URL: https://www.w3.org/TR/prov-overview/ (em inglês)
[PURI]
Phil Archer; Nikos Loutas; Stijn Goedertier; Saky Kourtidis. Study On Persistent URIs (em inglês). 17 de Dezembro de 2012. URL: https://philarcher.org/diary/2013/uripersistence/ (em inglês)
[RDA]
Research Data Alliance (em inglês). URL: https://rd-alliance.org (em inglês)
[RDF-SCHEMA]
Dan Brickley; Ramanathan Guha. W3C. RDF Schema 1.1 (em inglês). 25 de Fevereiro de 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/ (em inglês)
[RFC3986]
T. Berners-Lee; R. Fielding; L. Masinter. IETF. Uniform Resource Identifier (URI): Generic Syntax (em inglês). Janeiro de 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986 (em inglês)
[RFC4180]
Y. Shafranovich. IETF. Common Format and MIME Type for Comma-Separated Values (CSV) Files (em inglês). Outubro de 2005. Informational. URL: https://tools.ietf.org/html/rfc4180 (em inglês)
[RFC4627]
D. Crockford. IETF. The application/json Media Type for JavaScript Object Notation (JSON) (em inglês). Julho de 2006. Informational. URL: https://tools.ietf.org/html/rfc4627 (em inglês)
[RFC7089]
H. Van de Sompel; M. Nelson; R. Sanderson. IETF. HTTP Framework for Time-Based Access to Resource States -- Memento (em inglês). Dezembro de 2013. Informational. URL: https://tools.ietf.org/html/rfc7089 (em inglês)
[Richardson]
Richardson L.; Sam Ruby. O'Reilly. RESTful Web Services (em inglês). 2007. URL: https://restfulwebapis.org/rws.html (em inglês)
[SCHEMA-ORG]
Schema.org (em inglês). URL: https://schema.org/ (em inglês)
[SDW-BP]
Jeremy Tandy; Payam Barnaghi; Linda van den Brink. W3C. Spatial Data on the Web Best Practices (em inglês). 5 de Janeiro de 2017. W3C Note. URL: https://www.w3.org/TR/sdw-bp/ (em inglês)
[SIRI]
CEN. Service Interface for Real Time Information CEN/TS 15531 (prCEN/TS-OO278181) (em inglês). Outubro de 2006. URL: http://user47094.vs.easily.co.uk/siri/ (em inglês)
[SKOS-DESIGN]
Tom Baker; Sean Bechhofer; Antoine Isaac; Alistair Miles; Guus Schreiber; Ed Summers. Elsevier. Key Choices in the Design of Simple Knowledge Organization System (SKOS) (em inglês).Maio de 2013. Journal of Web Semantics 20: 35-49. URL: https://dx.doi.org/10.1016/j.websem.2013.05.001
[SKOS-PRIMER]
Antoine Isaac; Ed Summers. W3C. SKOS Simple Knowledge Organization System Primer (em inglês). 18 de Agosto de 2009. W3C Note. URL: https://www.w3.org/TR/skos-primer/ (em inglês)
[SchemaVer]
Alex Dean. Introducing SchemaVer for semantic versioning of schemas (em inglês). 2014. URL: https://snowplowanalytics.com/blog/2014/05/13/introducing-schemaver-for-semantic-versioning-of-schemas/ (em inglês)
[Tabular-Data-Primer]
Jeni Tennison. W3C. CSV on the Web: A Primer (em inglês). 25 de Fevereiro de 2016. W3C Note. URL: https://www.w3.org/TR/tabular-data-primer/ (em inglês)
[Tabular-Metadata]
Jeni Tennison; Gregg Kellogg. W3C. Metadata Vocabulary for Tabular Data (em inglês). 17 de Dezembro de 2015. W3C Recommendation. URL: https://www.w3.org/TR/tabular-metadata/ (em inglês)
[Turtle]
Eric Prud'hommeaux; Gavin Carothers. W3C. RDF 1.1 Turtle (em inglês).25 de Fevereiro de 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/ (em inglês)
[URLs-in-data]
Jeni Tennison. W3C. URLs in Data Primer (em inglês). 4 de Junho de 2013. W3C Working Draft. URL: https://www.w3.org/TR/urls-in-data/ (em inglês)
[VOCAB-DCAT]
Fadi Maali; John Erickson. W3C. Data Catalog Vocabulary (DCAT) (em inglês). 16 de Janeiro de 2014. W3C Recommendation. URL: https://www.w3.org/TR/vocab-dcat/ (em inglês)
[VOCAB-DQV]
Riccardo Albertoni; Antoine Isaac. W3C. Data on the Web Best Practices: Data Quality Vocabulary (em inglês). 15 de Dezembro de 2016. W3C Note. URL: https://www.w3.org/TR/vocab-dqv/ (em inglês)
[VOCAB-DUV]
Bernadette Farias Loscio; Eric Stephan; Sumit Purohit. W3C. Data on the Web Best Practices: Dataset Usage Vocabulary (em inglês). 15 de Dezembro de 2016. W3C Note. URL: https://www.w3.org/TR/vocab-duv/ (em inglês)
[WEBARCH]
Ian Jacobs; Norman Walsh. W3C. Architecture of the World Wide Web, Volume One (em inglês). 15 de Dezembro de 2004. W3C Recommendation. URL: https://www.w3.org/TR/webarch/ (em inglês)
[XHTML-VOCAB]
XHTML 2 Working Group. W3C. XHTML Vocabulary (em inglês). 27 de Outubro de 2010. URL: https://www.w3.org/1999/xhtml/vocab (em inglês)