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
Web Site: http://www.nic.br
Coordinator of the translation: Beatriz Rossi Corrales (biacorrales@nic.br)

Tradução Autorizada em Português do Brasil

Publicada em 30 de agosto de 2018

Esta versão:
http://www.w3c.br/traducoes/DWBP-pt-br/
Versão mais recente:
http://www.w3c.br/traducoes/DWBP-pt-br/
Versão original em inglês:
http://www.w3c.br/dwbp/
Errata:
http://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
Web Site: http://www.nic.br
Coordenadora da tradução: Beatriz Rossi Corrales (biacorrales@nic.br)
Parceiros na revisão da tradução:
http://lists.w3.org/Archives/Public/w3c-translators/2018JulSep/0031.html
Resumo dos comentários públicos da Candidata a Tradução Autorizada:
Comentários públicos são estimulados

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, o respeito a estas 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 propor diretrizes aos publicadores, de modo a tornar o gerenciamento de dados mais consistente e, consequentemente, promover a reutilização de dados; e 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 (em inglês) e Uso de Dados (em inglês).

Este documento foi publicado pelo Grupo de Trabalho Boas Práticas para Dados na Web 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). public-dwbp-comments@w3.org (subscribe, archives). Todos os comentários são bem-vindos.

Favor consultar o relatório de implementação do Grupo de Trabalho.

Este documento foi revisado pelos Membros do W3C, por desenvolvedores de software 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 à especificação e promover sua ampla implantação. Isto aperfeiçoa a funcionalidade e a interoperabilidade da Web.

Este documento foi produzido por um grupo operando em conformidade com a Politica de Patentes do W3C de 5 de Fevereiro de 2004. O W3C mantém uma lista pública de todas divulgações de patentes realizadas em conexão com os trabalhos entregues pelo grupo, e tal página também contém as instruções para divulgação de patentes. Um indivíduo que tenha conhecimento de uma patente que acredite conter Reivindicações Essenciais deverá divulgar as informações de acordo com a seção 6 da Política de Patentes do W3C.

Este documento é regido pelo Documento Processual de 1º de Setembro de 2015 do W3C.

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. Cada vez mais a Web está sendo usada para publicação de dados: o compartilhamento de dados abertos online 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 Aliança por Dados de Pesquisa (do inglês, 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 Biblioteca Nacional da França [BNF]e o crescimento sustentado na Nuvem de Dados Abertos Conectados (do inglês Linked Open Data Cloud)[LODC]são alguns dos exemplos desse crescimento do uso da Web para a publicação de dados.

No entanto, esse 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 conectar-se aos 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 essa 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 para dados na Web (em inglês).

Neste contexto torna-se fundamental prover diretrizes aos publicadores para que o gerenciamento de dados seja mais consistente. Tais orientações promoverão a reutilização dos dados e fortalecerão 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, as informações sensíveis sobre os 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 compartilhar algumas destas informações abertamente 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 de indivíduos inadvertidamente.

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íficos, envolvendo comunidades de usuários interessados nesses 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: a Especificação Geral sobre Feeds de Transporte (do inglês General Transit Feed Specification) [GTFS] e a Interface de Serviços para Informações em Tempo Real (do inglês 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 software.

As Boas Práticas abarcam diferentes aspectos relacionados à publicação e ao consumo de dados, 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 os 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 [DWBP-UCR]que representam cenários sobre como os dados são comumente publicados na Web e como são utilizados. Essa 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, as Boas Práticas para a Publicação de Dados Conectados (do inglês Best Practices for Publishing Linked Data) [LD-BP] do W3Csão uma boa referência. Existem recomendações específicas para expressar licenças, outras permissões e declarações de obrigações estabelecidas pela Open Digital Rights Language [ODRL-model],um conjunto de padrões relacionados a proveniência[PROV-Overview] e as Boas Práticas aqui apresentadas foram estendidas para abarcar orientações mais específicas acerca da facilidade de descoberta, facilidade de acesso e interoperabilidade de dados espaciais e temporais pelas 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, este também promove boas práticas para dados na Web em outros formatos abertos tais como o CSV. Métodos para o compartilhamento de dados tabulares, inclusive arquivos CSV, de modo a maximizar o potencial da Web para estabelecer links entre pontos de dados, são descritos no Primer de Dados Tabulares[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, na Web, dados de pesquisa. Ainda que os publicadores de dados sejam o nosso público primário, encorajamos todos os envolvidos em atividades correlatas a familiarizar-se com o tema. Realizamos todos os esforços possíveis no sentido de tornar esse 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 seria útil para entender melhor alguns aspectos deste documento.

3. Escopo

Essa seção não é normativa.

Este documento trata somente de Boas Práticas que:

Conforme mencionado acima, o fato de uma Boa Prática ter sido seguida ou não deve ser avaliado à luz do resultado pretendido e não sob a perspectiva da possível abordagem à implantação que é indicada no detalhamento de cada Boa Prática 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 as 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 proveniê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]. Um aspecto relevante desse fato é o princípio de identificação que diz que os URIs devem ser utilizados para identificar recursos. 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 a que possam ser referenciados e compor conexões, por meio de URIs, entre dois ou mais recursos. 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ço de nome, do inglês namespaces, são utilizados ao longo de todo este documento.

Prefixo Espaço de Nome IRI Descriçã
dcat http://www.w3.org/ns/dcat# Vocabulário de Catalogação de Dados, do inglês, Data Catalog Vocabulary (DCAT)
dct http://purl.org/dc/terms/ Dublin Core Metadata Initiative (DCMI)
dqv http://www.w3.org/ns/dqv# DWBP Vocabulário de Qualidade de Dados do DWBP, do inglês DWBP Data Quality Vocabulary (DQV)
duv http://www.w3.org/ns/duv# DWBPVocabulário de Utilização de Conjunto de Dados, do inglês DWBP Dataset Usage Vocabulary (DUV)
foaf http://xmlns.com/foaf/0.1/ Friend of a Friend (FOAF) Vocabulary
oa http://www.w3.org/ns/oa# Web Annotation Ontology
owl http://www.w3.org/2002/07/owl# Web Ontology Language (OWL)
pav http://pav-ontology.github.io/pav/ Provenance, Authoring and versioning Ontology [PAV]
prov http://www.w3.org/ns/prov# Ontologia de Proveniência, do inglês Provenance Ontology (PROV)
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# Resource Description Framework (RDF)
rdfs http://www.w3.org/2000/01/rdf-schema# RDF Schema vocabulary (RDFS)
skos http://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

Por que

Essa seção responde a duas perguntas cruciais:

  • Por que este tema é especificamente relevante para a publicação ou para a reutilização de dados na Web?
  • Como esta iniciativa estimula a publicação ou a reutilização 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 espera-se 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

Fornecemos uma 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 cumpridas. 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 aos consumidores de dados, com vista a superarem 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 Dados sobre os Desafios da 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[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 esses 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. Os dados não serão descobertos ou reutilizáveis por ninguém além do próprio publicador, caso os metadados fornecidos sejam insuficientes. 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, 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é um conjunto de dados completo, ou até mesmo 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 com um esquema 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.

Por que

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 user agents, que faz a 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 separadamente, devem ser fornecidos a partir do mesmo URL por meio de negociação de conteúdo e disponibilizados sob URIs separados, 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 Vocabulário de Catálogo de Dados [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 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.

Por que

Fornecer informações descritivas de conjuntos de dados de forma explícita possibilita que user agents 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) 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 W3Cpara descrever conjuntos de dados como, por exemplo, o Vocabulário de Catálogo de Dados[ 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.

Por que

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 ingdistribuiçõ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 apresentar 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 especificado dentro dos metadados, ou fora dos mesmos, em um documento em 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.

Por que

A disponibilização de informações de licença é fundamental para que os consumidores de dados avaliem a usabilidade dos dados. Os user agents podem utilizar a presença/ausência das informações de licença como um gatilho para a inclusão ou exclusão dos dados apresentados a um consumidor em potencial.

Resultado pretendido

Pessoas serão capazes de compreender a licença de dados, descrevendo eventuais restrições impostas à utilização de certos dados, 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 dos dados podem ser disponibilizadas por meio de um link, ou de uma cópia embutida dos termos da licença legível por pessoas. Também podem ser disponibilizadas para processamento através de 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:

  • O Creative Commons Rights Expression Language [CCREL]
  • O Open Digital Rights Language [ODRL-model]
  • O 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 user agent 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 Proveniê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 proveniê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 proveniência.

Boa Prática 5: Fornecer informações de proveniência dos dados

Fornecer informações completas sobre as origens dos dados e de quaisquer alterações que você tenha feito.

Por que

A proveniê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 proveniência.

Possível Abordagem para Implementação

A versão legível por máquina da proveniência de dados pode ser disponibilizada por meio de uma ontologia recomendada para descrever informações de proveniência, tais como a Ontologia de Proveniência do W3C, do inglês Provenance Ontology [PROV-O].

Como testar

Verifique se os metadados do conjunto de dados incluem informações de proveniência sobre o conjunto de dados em um formato legível por pessoas.

Verifique se a aplicação de computador pode processar automaticamente as informações sobre a proveniê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 dadosna 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 Vocabulário de Qualidade de Dados define conceitos tais como as medidas e métricas para avaliação da qualidade de cada dimensão [VOCAB-DQV]. Existem métodos inteligentes elaborados para adequarem-se a situações específicas de avaliação que dependem de indicadores de qualidade, mais especificamente, fragmentos de conteúdos de dados, fragmentos de dados de metainformaçã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 dos dados

Fornecer informações sobre a qualidade dos dados e adequação para fins específicos.

Por que

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 explicitamente declarados 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 de Qualidade de Dados 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 a 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 valer a pena. Com o objetivo de lidar com essas mudanças, novas versões de um conjunto de dados podem ser criadas. Infelizmente não há consenso sobre em que momento as alterações a um conjunto de dados devem ser consideradas como um conjunto de dados completamente diferente e não somente uma nova versão. A seguir, apresentamos alguns cenários onde a maioria dos publicadores concordaria que a revisão deve 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 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 majoritária, enquanto que o Cenário 3 provavelmente desencadearia somente uma versão minoritária. No entanto, decidir se as versões devem ser majoritárias ou minoritárias é menos importante do que evitar 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 e 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 editor 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 um indicador de versão

Designar e indicar um número de versão ou data para cada conjunto de dados.

Por que

As informações sobre a versão tornam a revisão de um conjunto de dados singularmente identificável. A singularidade 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 de 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 repetibilidade na pesquisa, permite comparações e evita confusão. A utilização de números de versão singulares que seguem uma abordagem padronizada pode também definir as expectativas do consumidor sobre como as versões diferem.

Resultado Pretendido

Os humanos e os agentes de software poderão facilmente determinar 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 uma esquematização numérica 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 para as especificações W3C specifications, descritas abaixo.

A Ontologia de Linguagens Web [OWL2-QUICK-REFERENCE] e a Ontologia de Proveniência, Autoria e Versionamento [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/distribuição fornece um número de versão ou data específicos em um formato inteligível por humanos.

Verifique se a aplicação do computador pode detectar/descobrir automaticamente e processar o número de versão ou data específicos de um conjunto de dados ou uma distribuição.

Evidência

Requisitos relevantes: R-DataVersion

Benefícios

  • Reuse
  • Trust

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

Fornecer um histórico completo de versão que explique as alterações feitas em cada versão.

Por que

Ao criar aplicações que utilizam dados é útil compreender a variabilidade 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 diferem umas das outras é tipicamente muito trabalhoso a não ser que um sumário destas diferenças seja fornecido.

Resultado Pretendido

Os humanos 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 diferem 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 changelog. Este último deve descrever exatamente em que cada uma das novas versões difere da versão anterior.

Evidência

Requisitos relevantes: R-DataVersion

Benefícios

  • Reuse
  • Trust

8.7 Identificadores de Dados

Os 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 http): 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”, 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 http://example.com/dataset.csv retornar nada além de do que um arquivo CSV. É recomendável que seja inteligível por humanos.
  3. Ao ser desreferenciado (buscado), um único URI pode oferecer o mesmo recurso em mais de um formato. http://example.com/dataset pode oferecer os mesmos dados em, digamos, CSV, JSON e XML. O servidor retorna o formato mais apropriado com base na negociação de conteúdo. .
  4. Um URI pode redirecionar-se a outro.
  5. Desreferenciar um URI aciona um programa de computador para ser executado 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: Utilizar URIs constantes como identificadores de conjuntos de dados

Identificar cada conjunto de dados por meio de um URI constante e cuidadosamente escolhido.

Por que

Adotar um sistema de identificação comum permite a básica identificação dos dados e comparação dos processos por qualquer um dos atores envolvidos de forma confiável. São pré-condições essenciais para o gerenciamento dod dados e a reutilização adequados.

Os desenvolvedores podem construir URIs dentro de seus códigos e portanto é importante que tais URIs sejam constantes 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 encontráveis e citáveis ao longo do tempo, independentemente do status, da disponibilidade ou do formato dos dados.

Possível Abordagem para Implementação

Para serem persistentes os URIs devem ser designados como tal. Muito já foi escrito sobre esse tópico - acesse, por exemplo, o Estudo da Comissão Europeia sobre URIs Constantes [PURI]que por sua vez propõe conexões a muitos outros recursos.

No caso de um editor de dados ser incapaz ou estiver relutante em gerenciar um espaço URI diretamente para constância, uma abordagem alternativa seria utilizar um serviço de redirecionamento tal qual Identificadores Constantes para a Web ou purl.org. Estes oferecem URIs constantes que podem ser redirecionados conforme necessário de forma que a localização eventual possa ser efêmera. O software por trás desses serviços se encontra disponível gratuitamente e portanto pode ser instalado e gerenciado localmente, caso necessário.

Identificadores de Objetos Digitais (DOIs) oferecem uma alternativa similar. Estes identificadores são definidos independentemente de qualquer tecnologia Web, mas podem ser anexados a um “URI stub”. 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 constante. Idealmente o site Web relevante inclui uma descrição de uma esquema de design e uma promessa crível de constância caso o editor já não puder manter o espaço URI por sí só.

Evidência

Requisitos relevantes: R-UniqueIdentifier, R-Citable

Benefícios

  • Reuse
  • Linkability
  • Discoverability
  • Interoperability

Boa Prática 10: Utilizar URIs constantes como identificadores dentro dos conjuntos de dados

Quando possível reutilizar os URIs de terceiros como identificadores dentro dos conjuntos de dados.

Por que

O poder da Web reside no efeito de Rede.. O primeiro telefone somente tornou-se útil quando um segundo telefone denotou que havia 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.

Estas ideias estão no centro de As Cinco Estrelas dos Dados Conectados, onde um ponto de dados conecta-se a outro, e no Hypermedia,onde links podem ser utilizados para levar dados adiante ou a serviços que possam agir sobre ou relacionar-se de alguma forma com os dados.

Isto é a Web dos Dados.

Resultado Pretendido

Os itens de dados serão relacionados por meio da Web criando um espaço de informação global igualmente acessível a humanos e 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 óbvias 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 [LD-BP] podem ser prontamente adaptados.

  • certifique-se de que os conjuntos de URI que você utiliza tenham sido publicados por um grupo ou uma organização confiável;
  • certifique-se de que os conjunto de URIs são de URIs constantes.

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 constância URI de forma a que outros possam adicionar valor aos seus dados ao estabelecerem conexões com eles.

Como testar

Verifique se dentro do conjunto de dados as referências a coisas que não se modificam ou que se modificam lentamente, 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. Idealmente os URIs deveriam solucionar, no entanto eles possuem valor como variáveis de escopo global caso sejam capazes de resolver ou não.

Evidência

Requisitos relevantes: R-UniqueIdentifier

Benefícios

  • Reuse
  • Linkability
  • Discoverability
  • Interoperability

Boa Prática 11: Designar URIs para versões e séries de conjuntos de dados

Designar URIs a versões individuais de conjuntos de dados assim como a séries em geral

Por que

Tal como em documentos, muitos conjuntos de dados são naturalmente categorizáveis 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 circunstâncias diferentes seria apropriado fazer uma referência à situação corrente (o conjunto de paradas de ônibus atuais, os representantes eleitos atuais, etc.) Em outras circunstâncias pode ser apropriado fazer referências à situação tal como ela se apresentava em um momento específico.

Resultado Pretendido

Humanos 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 (constante) para este documento é http://www.w3c.br/2016/PR-dwbp-20161215/. Este identificador aponta para um snapshot deste documento no dia de sua publicação. O URI para a “versão mais recente” deste documento é http://www.w3c.br/dwbp/ o qual é um identificador para documentos estreitamente relacionados, que estão sujeitos a alterações ao longo do tempo. No momento da publicação ambos os URIs solucionam para este documento. No entanto, quando a próxima versão deste documento for publicada, o URI da “versão mais recente” será alterada e redirecionada a esta; porém, o URI datado 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, R-Citable

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 a usabilidade dos dados. O melhor e mais flexível mecanismo do mundo é inútil a não ser que ofereça os dados em formatos que permitam o uso e a reutilização. Abaixo iremos detalhar as Boas Práticas ao selecionar formatos para os seus dados, tanto em nível de arquivos quanto de campos individuais. O W3C encoraja o uso de formatos que possam ser utilizados por um público o mais amplo possível e processados mais facilmente por sistemas de computação. Os formatos de fontes, tais como os depósitos de descarte 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: Utilizar formatos de dados padronizados inteligíveis por máquinas

Disponibilize os dados em um formato padronizado e inteligível por máquinas que seja bem apropriado para seu propósito ou uso em potencial.

Por que

À 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. Postar dados em um formato que não seja inteligível por máquinas impõe severas limitações para o seguimento da 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 humanos utilizando um computador e formatos que são inteligí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 enquanto são transformados. Em contraste, formatos de dados padronizados viabilizam tanto a interoperatividade 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 inteligíveis por máquinas também são neutros no que se refere à localidade.

Resultado Pretendido

As máquinas serão capazes de ler e processar facilmente os dados publicados na Web e os humanos poderão utilizar ferramentas computacionais normalmente disponíveis no domínio relevante para trabalhar com dados.

Possível Abordagem para Implementação

Torne os dados disponíveis em um formato de dados padronizado e inteligível por máquinas que seja facilmente analisável e 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 inteligível por máquinas.

Evidência

Requisitos relevantes: R-FormatMachineRead, R-FormatStandardized R-FormatOpen

Benefícios

  • Reuse
  • Processability

Boa Prática 13: Utilizar representações de dados de localidade neutra

Utilize estruturas e valores de dados de localidade neutra ou, quando isso não for possível, forneça metadados sobre a localidade utilizada pelos valores de dados.

Por que

Os valores de dados que são inteligí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 más interpretações do que valores que usam uma das muitas e diversas interpretações culturais. 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 07 de abril ou 04 de julho, 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. Ao utilizar um formato de localidade neutra, os sistemas evitam a necessidade de estabelecer regras intercambiáveis específicas que variam de acordo com o idioma ou a localização do usuário. Quando os dados já estão em um formato de localidade específica, tornam explícitas a localidade e a linguagem por meio do fornecimento de parâmetros que permitem aos usuários determinar quão prontamente poderão trabalhar com os dados e habilitar serviços de tradução automatizados.

Resultado Pretendido

Humanos 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 valores dos dados sejam processados de forma precisa sem análises complexas ou más interpretações 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 intercambiar uma estrutura de dados tal como:

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

Alguns conjuntos de dados contêm valores que não são ou não podem ser renderizados em um formato de localidade neutra. Isto é particularmente verdadeiro para todos os valores de texto em idioma natural. Para cada campo de dados que possa conter textos de localidade afetada ou de idioma natural, deveria haver uma aba de idioma associada, utilizada para indicar o idioma e a localização do dado. Essa informação de localidade pode ser utilizada ao analisar os dados ou para assegurar a apresentação e o processamento adequados do valor por parte do consumidor. BCP47 [BCP47] fornece o padrão para a identificação do idioma e da localidade e, informativamente, CLDR [CLDR] é a fonte de ambos, representando formatos especificamente localizados e a referência para os valores de dados de localidade específica.

Como testar

Verifique se os valores dos dados sensíveis à localização 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, R-MetadataAvailable, R-GeographicalContext, R-FormatMachineRead

Benefícios:

  • Reuse
  • Comprehension

Boa Prática 14: Fornecer dados em formatos múltiplos

Disponibilize dados em formatos múltiplos quando mais de um formato for adequado ao uso pretendido ou potencial.

Por que

Disponibilizar dados em mais de um formato reduz os custos decorrentes da transformação de dados e minimiza a possibilidade de introduzir 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 com maior eficiência. Por último, aumenta o número de instrumentos 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 mais prováveis de serem necessários e alternativas que possivelmente serão úteis no futuro. Os editores de dados devem equilibrar o esforço necessário para disponibilizar os dados em muitos formatos em relação ao custo de fazê-lo; no entanto, fornecer pelo menos uma alternativa aumentará significativamente a usabilidade dos dados. Para disponibilizar dados em mais de um formato você pode utilizar negociação de conteúdo conforme descrito no documento Usos das Boas Práticas sobre negociações de conteúdo para o fornecimento de dados em formatos múltiplos.

Uma palavra de advertência: identificadores de localidade dentro de conjuntos de dados que possam ser expostos como identificadores de fragmento em URIs devem ser consistentes através dos diversos 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

Benefícios

  • Reuse
  • Processability

8.9 Vocabulários de Dados

Vocabulários 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, tesauro, 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 aquelas 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, por exemplo, vocabulários que estruturam as descrições de recursos em conjuntos de dados (concectados). Um conceito advindo de um tesauro, digamos, “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 os termos nestes vocabulários. Modelos mais simples foram propostos para representá-los e permutá-los, tais como o modelo de dados ISO 25964 [ISO-25964] ou o Sistema Simples de Organização de Conhecimento do W3C [SKOS-PRIMER].

Boa Prática 15: Reutilizar vocabulários preferencialmente padronizados

Utilize termos advindos de vocabulários compartilhados, preferencialmente os padronizados, para codificar dados e metadados.

Por que

A utilização de vocabulários já em uso por outros captura 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 utilização de vocabulários compartilhados para metadados (especialmente os metadados estruturais, de proveniê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 de padrões ajuda a evitar ambiguidade e conflitos entre elementos e valores similares.

Resultado Pretendido

A interoperabilidade e o consenso entre os publicadores de dados e consumidores serão melhorados.

Possível abordagem para Implementação

A seção de Vocabulários no documento Boas Práticas para a Publicação de Dados Conectados [LD-BP] do W3C fornece orientação sobre a descoberta, avaliação e seleção de vocabulários existentes.

Organizações tais como o Consórcio Geoespacial Aberto (OGC), ISO, W3C, WMO, ISO, W3C, WMO, bibliotecas e serviços de pesquisa de dados, etc., fornecem listagens 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 a sua documentação - forneça contextualização suficiente (em formatos inteligíveis por humanos 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 por diversas fronteiras. O tesauro multilíngue da União Europeia, o Eurovoc, fornece um exemplo primoroso.

Como testar

Utilize repositórios de vocabulários como o repositório de Vocabulários Abertos Conectados ou listagens de serviços mencionados em Boas Práticas específicas de tecnologia, tais como as Boas Práticas para a Publicação de Dados Conectados [LD-BP], ou o Contexto Inicial Fundamental para RDfs e JSON-LD; 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-MetadataStandardized, R-MetadataDocum, R-QualityComparable, R-VocabOpen, R-VocabReference

Benefícios

  • Reuse
  • Processability
  • Comprehension
  • Trust
  • Interoperability

Boa Prática 16: Escolher o nível correto de formalização

Opte por um nível de semântica formal que se ajuste tanto aos dados quanto às aplicações mais prováveis.

Por que

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 transmitem significados detalhados e 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ço de produção e compreensão, o que poderia dificultar sua reutilização, comparação e conexão por bases de dados que deles fazem uso.

Caso os dados sejam suficientemente ricos para conter 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 é claramente apropriado [OWL2-PROFILES].

No entanto, não há nada de complicado em listas 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 editor 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 mostrados em um mapa. Portanto, o equilíbrio deve ser atingido tendo em mente que o objetivo não é simplesmente compartilhar seus dados, mas sim sua reutilização por outros.

Resultado Pretendido

Os casos de aplicação mais prováveis serão suportados 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 comumente utilizado, 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 gama de restrições que não se aplica ao seu caso. Neste cenário é geralmente válido contatar os publicadores do vocabulário e conversar sobre o caso. Eles podem muito bem ser capazes de remover essa restrição e proporcionar orientação adicional sobre como o vocabulário é utilizado de forma mais ampla.

O W3C opera uma lista de discussão em public-vocabs@w3.org [arquivo] onde questões referentes ao uso e desenvolvimento dos vocabulários podem ser discutidas.

Caso esteja criando seu próprio vocabulário, mantenha as restrições semânticas ao mínimo que atenda às suas necessidades e, novamente, de forma a incentivar a possibilidade de reutilização por terceiros. Como exemplo, os designers da própria (muito utilizada) ontologia SKOS, minimizaram seu compromisso ontológico questionando todos os axiomas formais sugeridos para suas classes e propriedades. Frequentemente estes foram rejeitados porque seu uso, embora benéfico para muitas aplicações, teria criado inconsistências formais para os dados de outras aplicações, o que tornaria o SKOS inteiramente não utilizável para estas. Como exemplo, a propriedade skos:broader 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 tesauros [SKOS-DESIGN]. Ao selecionar um vocabulário busque evidências do tipo “design para amplo uso”.

Outro exemplo deste “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 a definição de tipos de objetos com que as propriedades podem ser utilizadas. Por exemplo, apenas “espera-se” que os valores da propriedade autor sejam do tipo Organização ou Pessoa. Autor “pode ser usado” no tipo CreativeWork, mas esta não é uma restrição rigorosa. Novamente, esta abordagem ao design torna o schema.org uma boa escolha como vocabulário para usar ao codificar dados para compartilhamento.

Como testar

Esta é quase sempre uma questão de julgamento subjetivo para a qual não há um teste objetivo. Como diretriz geral:

  • Estão sendo utilizados vocabulários comuns como o Dublin Core e o schema.org?
  • Os fatos simples estão declarados de forma simples e podem ser facilmente recuperados?
  • Para idiomas de representação de conhecimento formal, aplicar um mecanismo de inferência sobre dados que utilize um determinado vocabulário e não produza declarações demasiadas e desnecessárias para as aplicações de destino.

Evidência

Requisitos relevantes: R-VocabReference, R-QualityComparable

Benefícios

  • Reuse
  • Comprehension
  • Interoperability

8.10 Acesso de Dados

Fornecer acesso fácil aos dados na Web permite que tanto humanos quanto máquinas possam beneficiar-se do compartilhamento de dados utilizando a infraestrutura da Web. Por padrão, a Web oferece acesso utilizando os métodos do Protocolo de Transferência de Hipertexto (HTTP). Isto proporciona acesso aos dados em um nível atômico de transação; e 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.

Na abordagem de download em massa os dados geralmente são o 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 editor de dados pode oferecer APIs para dar suporte a 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 estar disponíveis para permitir que terceiros pesquisem e recuperem automaticamente estes dados.

Além de auxiliar a automatizar as pipelines de dados em tempo real, as APIs são adequadas para todos os tipos de dados na Web. Embora geralmente demandem mais trabalho em relação à postagem de arquivos para download, os editores 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; sendo o incentivo da publicação continuada dos dados e a promoção de seu próprio trabalho as motivações do usuário para fazê-lo. Uma segunda abordagem menos amistosa é exigir o registro antes que os dados possam ser acessados Em ambos os casos o Vocabulário de Utilização de Conjuntos de Dados [VOCAB-DUV] fornece uma estrutura para a representação de tais informações. Ao coletar dados dos usuários, o editor deve explicar por que 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

Permitir que os consumidores recuperem o conjunto de dados completo em uma única solicitação.

Por que

Quando dados da Web estiverem distribuídos através de de muitas URIs, mas podem ser organizados logicamente como um container, acessar os dados em massa pode ser útil. Acesso em massa fornece um meio consistente de tratar os dados como um conjunto de dados. Acessar dados individualmente ao longo de muitas recuperações pode ser difícil e, caso utilizado para reagrupar o conjunto de dados completo, pode levar a abordagens inconsistentes ao tratamento 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 dedicados.

Possível Abordagem para Implementação

Dependendo da natureza dos dados e das necessidades dos consumidores, abordagens possíveis poderiam incluir o seguinte:

  • 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 uma URI. Para conjuntos de dados maiores, o arquivo também pode ser comprimido.
  • Hospedagem de uma API que inclua a habilidade de recuperar um download em massa, além de consultas dinâmicas. Esta abordagem é útil para que seja possível capturar um único snapshot 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 ou GridFTP.

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 recuperado com uma única solicitação.

Evidência

Requisitos relevantes: R-AccessBulk

Benefícios

  • Reuse
  • Access

Boa Prática 18: Fornecer Subconjuntos para Conjuntos de Dados Extensos

Caso seu conjunto de dados seja extenso, permita que usuários e aplicações trabalhem prontamente por meio do uso de subconjuntos de seus dados.

Por que

Conjuntos de dados muito extensos podem ser difíceis de mover de um lugar a outro. Também pode ser inconveniente para os usuários armazenar ou analisar um conjunto de dados extenso. Os usuários não deveriam ter que fazer download de um conjunto de dados completo se apenas necessitam de um subconjunto do mesmo. Além do mais as aplicações da Web que acessam conjuntos de dados extensos operarão com melhor desempenho caso seus desenvolvedores possam apropriar-se das vantagens do “carregamento lento”, trabalhando com porções menores de um todo e irem puxando novas porções apenas quando necessário. A habilidade de trabalhar com subconjuntos de dados também permite que o processamento offline funcione com mais eficiência. As aplicações em tempo real beneficiam-se particularmente, pois podem ser atualizadas mais rapidamente.

Resultado Pretendido

Humanos e aplicações serão capazes de acessar subconjuntos de um conjunto de dados em vez de todo ele, com uma proporção maior de dados necessitados em relação a não necessitados para o maior número de usuários. Conjuntos de dados estáticos que os usuários no domínio considerariam extensos demais serão descarregáveis em porções menores. As APIs formarão fatias ou subconjuntos filtrados de dados disponíveis, a granularidade dependendo das necessidades do domínio e das demandas de desempenho na aplicação da Web.

Possíveis Abordagens à Implementação

Considere os casos de uso esperados para o seu conjunto de dados 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 necessitados - e poucos dados não necessitados - 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).

Outra forma de formar subconjuntos a partir de um conjunto de dados é dividi-lo em unidades menores e tornar tais unidades disponíveis para download, ou para visualização de forma individualizada.

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 em separado por meio de dados. Uma forma de fazê-lo é indicando “fatias” utilizando Vocabulário do Cubo de Dados RDF..

Como testar

Verifique se o conjunto de dados como um todo pode ser recuperado por meio de solicitações múltiplas que recuperem unidades menores.

Evidência

Requisitos Relevantes: R-Citable, R-GranularityLevels, R-UniqueIdentifier, R-AccessRealTime

Benefícios

  • Reuse
  • Linkability
  • Access
  • Processability

Boa Prática 19: Utilizar a negociação de conteúdo para disponibilizar dados em formatos múltiplos

Além de extensões de arquivos, utilize negociação de conteúdo para disponibilizar dados em formatos múltiplos.

Por que

É possível disponibilizar dados em uma página HTML com dados inteligíveis por humanos mesclados a dados inteligíveis por máquina usando RDFa, por exemplo. No entanto, como a Arquitetura da Web [WEBARCH] e o DCAT [VOCAB-DCAT] deixa claro, um recurso, (como por exemplo, um conjunto de dados) pode ter muitas representações. Os mesmos dados podem estar disponíveis como JSON, XML, RDF, CSV e HTML. Estas representações múltiplas podem ser disponibilizadas por meio de uma API, entretanto devem ser disponibilizadas a partir do mesmo URL utilizando-se a negociação de conteúdo 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 irá habilitar recursos diversos ou representações diferentes do mesmo recurso a ser disponibilizado de acordo com a solicitação feita pelo cliente.

Abordagem Possível para Implementação

Uma abordagem possível para implementação é configurar o servidor da 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 Requisição HTTP.

Evidência

Requisitos Relevantes: R-FormatMachineRead, R-FormatMultiple

Benefícios

  • Reuse
  • Access

Boa Prática 20: Fornecer acesso em tempo real

Quando os dados forem produzidos em tempo real, disponibilize-os na Web em tempo real ou quase em tempo real.

Por que

A presença de dados em tempo real na Web viabiliza o acesso a dados críticos sensíveis ao tempo 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 editor 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 e 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.

Abordagem Possível para Implementação

Uma possível abordagem para implementação é que os editores configurem um Serviço da Web que forneça uma conexão de forma que, ao receberem dados em tempo real pelo Serviço da Web, estes possam ser instantaneamente disponibilizados aos consumidores por polling ou streaming.

Caso os dados sejam verificados com pouca frequência pelos consumidores, os dados em tempo real poderão ser consultados 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 somente de leitura.

Caso os dados sejam verificados com frequência pelos consumidores, uma implementação de dados por streaming poderá ser mais apropriada quando os dados forem enviados por meio de uma API. Embora as técnicas de streaming estejam além do escopo desta boa prática, há muitos protocolos e tecnologias padronizados disponíveis (por exemplo, Eventos Enviados pelo Servidor, WebSocket, EventSourceAPI) para clientes que recebem atualizações automáticas do servidor.

Como Testar

Para testar acesso de dados em tempo real adequadamente, 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 compostos de vários sistemas de computador. Por exemplo, testes que dependam de marcas 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

Benefícios

  • Reuse
  • Access

Boa Prática 21: Fornecer dados atualizados

Disponibilize os dados de forma atualizada e torne explícita a frequência de atualização.

Por que

A disponibilidade dos dados na Web deve corresponder rigorosamente à data de criação ou coleta dos dados, talvez 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 a reutilização dos dados.

Resultado Pretendido

Os dados na Web serão atualizados em tempo hábil para que os dados disponíveis mais recentes disponibilizados online reflitam em geral 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.

Abordagem Possível para Implementação

Novas versões do conjunto de dados podem ser publicadas na Web em uma programação regular, seguindo as Boas Práticas para Versionamento de Dados. A publicação na Web pode fazer parte do processo de liberação de novas versões dos dados. Tornar a publicação na Web um item a ser entregue neste 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 inteligível por humanos com a frequência esperada de publicação e também fornecer metadados inteligíveis por máquinas indicando a frequência.

Como testar

Verifique se a frequência das atualizações encontra-se declarada e a última cópia publicada na Web não seja mais antiga do que a data prevista pela frequência de atualização declarada.

Evidência

Requisitos relevantes: R-AccessUptodate

Benefícios

  • Reuse
  • Access

Boa Prática 22: Fornecer uma justificativa para dados não disponíveis

Para dados não disponibilizados, forneça uma explicação como podem ser acessados e quem pode fazê-lo.

Por que

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 podem ser disponibilizados sob condições diferentes.

Abordagem Possível para Implementação

Dependendo do contexto máquina/humanos, existem várias maneiras de indicar indisponibilidade de dados. Os publicadores de dados podem publicar um documento em HTML – que dá uma explicação inteligível por humanos 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 inteligíveis por humanos. Exemplos dos códigos de status incluem: 303 (veja outros), 410 (removido permanentemente), 503 (serviço *fornecer dados* não disponível).

Como testar

Onde o conjunto de dados incluir referências a dados que não estejam mais disponíveis ou não estejam disponíveis para todos os usuários, verifique se são concedidas explicações sobre o que está faltando e instruções para obter acesso (se possível). 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, R-SensitivePrivacy, R-SensitiveSecurity

Benefícios

  • Reuse
  • Trust

8.10.1 APIs de Acesso de Dados

Boa Prática 23: Disponibilizar dados por meio de uma API

Ofereça uma API para servir os dados caso você tenha recursos para tanto.

Por que

Uma API oferece aos consumidores de seus dados maior flexibilidade e processabilidade. Ela pode habilitar o uso de dados em tempo real, realizar filtragens a partir de solicitações e tem a capacidade de trabalhar com os dados em um nível atômico. Caso o seu conjunto de dados seja extenso, 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 aplicalções da Web terão a capacidade de obter dados específicos consultando uma interface programática.

Abordagem possível 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 da Web. No entanto, não é necessário construir uma a partir do zero. Caso utilizar uma plataforma de gerenciamento de dados, tal como a CKAN, você poderá habilitar uma API já existente. Muitas estruturas de desenvolvimento da Web incluem suporte para APIs e também existem 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 da 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 que a API responda como previsto.

Evidência

Requisitos Relevantes: R-AccessRealTime, R-AccessUpToDate

Benefícios
  • Reuse
  • Processability
  • Interoperability
  • Access

Boa Prática 24: Utilizar Padrões da Web como base para as APIs

Ao desenvolver APIs, utilize um estilo arquitetural que tenha por base as tecnologias da própria Web.

Por que

As APIs construídas nos padrões da Web alavancam as forças da Web. Por exemplo, utilizar verbos HTTP como métodos e URLs que se orientam diretamente a recursos individuais, ajuda a evitar o acoplamento estreito entre solicitações e respostas, assim produzindo uma API que é de simples manutenção e pode ser facilmente compreendida e utilizada por muitos desenvolvedores. A apatridia da Web pode ser um reforço na permissão de um escalonamento rápido, e o uso da hipermídia possibilita ricas interações com a sua API.

Resultado Pretendido

Desenvolvedores com alguma experiência em APIs com base nos padrões da Web, como REST, terão um entendimento inicial de como utilizar a API. A manutenção da API será também mais fácil.

Abordagens possíveis para implementação

REST (REpresentational State Transfer)[Fielding][Richardson] é um estilo arquitetônico que, quando usado em uma API, da Web, tira proveito 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 forte 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 da 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 a considerar é fazer uma API, de hipermídia, uma que responda com links bem como com dados. 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 autodocumentado.

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, R-UniqueIdentifier

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

Boa Prática 25: Fornecer a documentação completa para sua API

Forneça informações completas na Web sobre sua API.Atualize a documentação conforme adicionar características ou introduzir modificações.

Por que

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 que suporta 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 API para os clientes.

Abordagem Possível 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 propósito de cada uma, detalhando os parâmetros que esta permite, assim como quais retorna, e dando um ou mais exemplos de seu uso. Uma tendência 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 para seus casos de utilização. Já existem ferramentas disponíveis para criar este tipo de documentação de forma rápida, como Swagger, io-docs, OpenApis, e outras. É importante dizer que a API também deve ser autodocumentada, 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 bugs.

A qualidade da documentação também está relacionada ao uso e feedback dos desenvolvedores. Tente obter feedbacks constantes de seus usuários sobre documentação.

Como testar

Verifique se todas as chamadas habilitadas por sua API estão descritas na sua documentação. Assegure-se de estar fornecendo detalhes sobre quais parâmetros são necessários e quais são opcionais, e o que cada chamada retorna.

Verifique o Tempo para a Primeira Chamada Bem Sucedida (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

Benefícios
  • Reuse
  • Trust

Boa Prática 26: Evitar Modificações que Quebrem sua API

Evite modificações à sua API que quebrem o código do cliente e, quando houver evolução, informe seus desenvolvedores sobre quaisquer modificações feitas na sua API.

Por que

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 quebrem sua API minimiza a quebra 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 quebre a API, tomem providências.

Resultado Pretendido

O código do desenvolvedor continuará a operar. O desenvolvedor irá saber das melhorias que você implementou e poderá utilizá-las. Modificações que quebrem 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 os possibilitará evitar as quebras, aumentando a confiança. Modificações à API serão anunciadas no site de documentação da API.

Abordagem Possível 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 afetam 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 que você projetou inicialmente, então será necessário um design completamente novo - e isto significa modificações que quebram o código do cliente. Neste caso é melhor implementar as alterações como uma nova REST API, com um URI de recurso diferente.

Se você está utilizando um estilo de arquitetura que não permite fazer alterações moderadamente significantes sem quebrar 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 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 subscreverem-se. Por este meio, você poderá anunciar modificações e proporcionar também um bom mecanismo para receber feedbacks. Ademais a lista permite que os usuários ajudem-se mutuamente.

Como testar

Libere modificações inicialmente para 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, R-APIDocumented

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 editores provavelmente irão querer ou precisar remover dados da Web ao vivo – ponto o qual 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 é, quais passos devem ser dados pelos publicadores para indicar quais dados foram removidos ou arquivados. Simplesmente delatar um recurso da Web é uma má prática. Nesta circunstância, desreferenciar 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 os identificadores

Ao remover dados da Web, preserve o identificador e forneça informações sobre o recurso arquivado.

Por que

O desreferenciamento do URI é a interface primária para os dados na Web. Caso o desreferenciamento 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 editor ou um terceiro tenha arquivado o dado, é muito menos provável que aquela cópia arquivada possa ser encontrada se o URI esteja efetivamente quebrado.

Resultado Pretendido

O URI de um recurso irá sempre desreferenciar para o recurso ou redirecionar para informações a respeito.

Abordagem Possível 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). A partir da especificação:

A resposta 410 destina-se principalmente a auxiliar na tarefa de manutenção da Web notificando o recipiente de que o recurso encontra-se intencionalmente indisponibilizado e 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 da 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 desreferê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 - seja utilizando o código de resposta 410 ou o código 303, conforme o mais apropriado.

Evidência

Requisitos Relevantes:R-AccessLevel, R-PersistentIdentification

Benefícios

  • Reuse
  • Trust

Boa Prática 28: Avaliar a cobertura do conjunto de dados

Avalie a cobertura de um conjunto de dados antes de sua preservação.

Por Que

Uma bloco de dados da Web é, por definição, dependente do resto do gráfico global. Este contexto global influencia o sentido da descrição dos recursos encontrados no conjunto de dados. Idealmente, a preservação de um determinado conjunto de dados envolveria a conservação de todo o seu contexto. Ou seja, toda a Web dos Dados.

Na momento de 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 os quais poucos dos vocabulários utilizados e/ou recursos apontados já se encontram preservados em algum lugar devem ser assinalados como em risco.

Resultado Pretendido

Os usuários poderão fazer uso dos dados arquivados por muito tempo.

Abordagem Possível 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 que está sendo considerado para preservação.

Como testar

Não é possível determinar o que estará disponível em, digamos, 50 anos. 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

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 perícia. Os publicadores de dados querem garantir que os dados publicados atendam às necessidades dos consumidores de dados e, para esta finalidade, o feedback dos usuários é crucial. O feedback traz benefícios tanto para publicadores como consumidores, ajudando os primeiros a melhorar a integridade de seus 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, o feedback também deve ser disponibilizado publicamente para que outros consumidores de dados possam examiná-lo. Disponibilizar o feedback 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 feedback dos consumidores de dados, incluindo o registro no site, formulários de contato, seleção de avaliações de qualidade, pesquisas e caixas de comentários para blogs. Sob a perspectiva de de uma máquina, o editor 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 editores e consumidores de dados. Feedback disponibilizado publicamente deve ser exibido em um formato inteligível por humanos.

Esta seção fornece algumas Boas Práticas a serem seguidas por publicadores de dados visando possibilitar que os consumidores deem feedback. Tal feedback pode servir para humanos ou máquinas.

Boa Prática 29: Coletar feedback de consumidores de dados

Fornecer meios facilmente encontráveis para que os consumidores deem feedback.

Por que

Receber feedback ajuda os publicadores a compreender as necessidades de seus consumidores de dados, além de auxiliá-los a melhorar a qualidade de seus dados publicados. Também aumenta a confiabilidade ao demonstrar aos consumidores que o editor se importa e preocupa-se em atender à suas necessidades. Especificar claramente um mecanismo de feedback remove a inconveniência para o consumidor de ter que procurar uma maneira de fornecer feedback.

Resultado Pretendido

Os consumidores de dados poderão fornecer feedback e avaliações sobre os conjuntos de dados e distribuições.

Abordagem Possível para implementação.

Forneça aos consumidores de dados um ou mais mecanismos para o envio de feedback, incluindo (mas não limitando a) um formulário de contato, teclas de apontar ou clicar para avaliação de qualidade de dados ou uma caixa de comentários. Para aproveitar ao máximo o feedback recebido 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 feedback; 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 de Uso de Conjuntos de Dados[VOCAB-DUV].

Como testar

Verifique se pelo menos um mecanismo de feedback foi fornecido e se este pode ser facilmente encontrável por consumidores de dados.

Evidência

Requisitos Relevantes: R-UsageFeedback, R-QualityOpinions

Benefícios

  • Reuse
  • Comprehension
  • Trust

Boa Prática 30: Disponibilizar feedback

Disponibilize publicamente mecanismos de feedback de consumidor sobre conjuntos de dados e distribuições.

Por que

Ao compartilhar feedback com consumidores, os publicadores demonstram aos usuários que suas considerações estão sendo levadas em conta, e podem evitar o envio de relatórios de bug duplicados. Compartilhar feedback também ajuda os consumidores a compreender quaisquer questões que possam afetar sua capacidade de utilizar dados, assim como fomenta um sentido 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 editor está abordando ativamente os problemas conforme o necessário. Também poderão determinar se outros usuários já forneceram feedbacks semelhantes, aliviando-os do trabalho de enviar relatórios desnecessários e evitando que os mantenedores tenham que lidar com duplicidade.

Abordagem Possível para a Implementação

O feedback pode ficar disponível como parte de uma página da Web em HTML, mas também pode ser fornecido em um formato inteligível por máquinas utilizando o Vocabulário de Uso de Conjuntos de Dados [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, R-QualityOpinions

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 de outro modo melhorar dados brutos ou dados previamente processados. Esta ideia e outros conceitos semelhantes contribuem para tornar os dados 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 cautela, pois preocupações éticas podem surgir. Na pesquisa científica, cuidados devem ser tomados para evitar que o enriquecimento distorça resultados ou conclusões estatísticas. Em se tratando de dados sobre indivíduos, 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.

Este seção fornece algumas recomendações a serem observadas por editores 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.

Por que

O enriquecimento pode acentuar consideravelmente a processabilidade, especialmente no caso de dados não estruturados. Em algumas circunstâncias, valores 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 da coleta de resultados adicionais da mesma forma como os dados originais ou combinando dados originais com outros conjuntos de dados. Publicar conjuntos de dados mais completos pode aumentar a confiabilidade, se feito de maneira adequada e ética. Derivar valores adicionais que sejam de utilidade geral economiza tempo para o usuário e incentiva mais tipos de reutilização. Há muitas técnicas inteligentes que podem ser usadas 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 desses valores. A estrutura será verificada e a utilidade aumentada caso providências ou atributos relevantes sejam adicionados, porém somente se a adição não distorcer os resultados analíticos, a significância ou a potência estatística.

Abordagem Possível para Implementação

As técnicas para o enriquecimento de dados são complexas e se estendem além do escopo deste documento, que pode somente sublinhar tais possibilidades.

A aprendizagem de máquina pode ser facilmente aplicada ao enriquecimento de dados. Os métodos incluem aqueles focalizados 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 derivados 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 a 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 etiquetados como tal, e deve ser possível recuperar qualquer valor original substituído por enriquecimento.

Sempre que o licenciamento 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 determinada pelo valor 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 exemplo, por meio de pesquisas ou pelo rastreio de pedidos diretos). Documentar como você mensura a demanda pode tornar demonstrável o valor agregado.

Caso você venha a enriquecer os dados de outra pessoa, seria prudente oferecer esses enriquecimentos de volta ao editor 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 inferencial esteja identificado como tal, e se quaisquer dados substituídos ainda estejam disponíveis.

Evidência

Requisitos Relevantes: R-DataEnrichment, R-FormatMachineRead, R-ProvAvailable

Benefícios

  • Reuse
  • Comprehension
  • Trust
  • Processability

Boa Prática 32: Fornecer Apresentações Complementares

Enriqueça seus dados apresentando-os em formas complementares e imediatamente informativas, tais como visualizações, tabelas, aplicações da Web ou resumos.

Por que

Dados publicados online destinam-se a informar terceiros sobre seu assunto. Porém, apenas publicar conjuntos de dados para download ou acesso à API relega 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

Apresentações complementares dos dados irão permitir a consumidores humanos ter uma percepção imediata dos dados por meio de apresentações de fácil entendimento.

Possível Abordagem para Implementação

Uma maneira muito simples de proporcionar percepções imediatas é publicar um resumo analítico em uma página HTML. Incluir dados somativos em gráficos ou tabelas pode ajudar o usuário a explorar o resumo e entender rapidamente o sentido dos dados.

Caso você tenha meios de criar visualizações ou aplicações Web interativas que utilizem os dados, estará proporcionando 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 a reutilização.

Como Testar

Verifique se o conjunto de dados se encontra acompanhado de algum conteúdo adicional interpretativo que pode ser percebido sem o download dos dados ou a necessidade de invocar uma API.

Evidência

Requisitos Relevantes: R-DataEnrichment

Benefícios

  • Reuse
  • Comprehension
  • Access
  • Trust

8.14 Republicação

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 reembalagem de dados em um novo formato, como uma tradução. Os republicadores têm algumas responsabilidades que são exclusivas desta maneira de publicação na Web. Este seção fornece recomendações que devem ser observadas ao republicar dados.

Boa Prática 33: Fornecer Feedback ao Editor Original

Informe o editor original quando você está reutilizando seus dados. Informe-o caso encontre um erro ou tenha sugestões ou elogios a tecer.

Por que

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 a destinação dos dados publicados 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 tornará mais fácil para os editores 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. Siga a rota preferida dos publicadores para dar feedback. Caso não forneçam uma rota, procure esta informação de contato no site da Web que hospeda os dados.

Como Testar

Verifique se você tem um registro de pelo menos uma comunicação informando ao editor sobre a utilização de tais dados.

Evidência

Requisitos relevantes: R-TrackDataUsage, R-UsageFeedback, R-QualityOpinions

Benefícios

  • Reuse
  • Interoperability
  • Trust

Boa Prática 34: Seguir os Termos de Licenciamento

Encontre e siga os requisitos de licenciamento fornecido pelo editor original do conjunto de dados.

Por que

O licenciamento fornece uma estrutura jurídica para utilizar o trabalho de outra pessoa. Ao respeitar os requisitos do editor original, você promove relações amigáveis entre você e o editor. Não é necessário preocupar-se com ações jurídicas caso respeite o que o editor original deseja. Além disso, compreender o licenciamento original ajudará a determinar qual licenciamento 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 licenciamento, o que provavelmente os estimulará a continuar publicando dados. Reutilizadores de dados poderão eles próprios licenciar seus trabalhos derivados de maneira adequada.

Possível Abordagem para Implementação

Leia o licenciamento original e respeite seus requisitos. Caso este solicitar licenciamento 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 editor original e pergunte a ele qual é o licenciamento aplicável.

How to Test

Leia todo o licenciamento 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, R-LicenseLiability,

Benefícios

  • Reuse
  • Trust

Boa Prática 35: Citar a Publicação Original

Reconheça a fonte de seus dados nos metadados. Caso forneça uma interface de usuário, inclua a citação claramente na interface.

Por que

Dados só são úteis quando confiáveis. Identificar a fonte é o maior indicativo de confiabilidade por dois motivos: em primeiro lugar, o usuário pode julgar a confiabilidade dos dados a partir da reputação da fonte e, em segundo, citar a fonte sugere que você mesmo é confiável como reeditor. Além de informar o usuário final, citar ajuda os editores 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 proveniência e ainda ajuda outros a trabalhar com os dados.

Resultado Pretendido

Usuários finais poderão avaliar a confiabilidade dos dados que estão visualizando e os esforços dos publicadores originais serão reconhecidos. Também será possível rastrear a origem dos dados na Web até o editor 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 inteligível por humanos claramente visível em qualquer interface de usuário.

Evidência:

Requisitos Relevantes: R-Citable, R-ProvAvailable, R-MetadataAvailable, R-TrackDataUsage

Benefícios

  • Reuse
  • Discoverability
  • Trust

9. Glossário

Esta seção não é normativa.

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.

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 (TDR), também chamado ocasionalmente de Serviço de Arquivamento de Longo Prazo (LTA). Muitas vezes, tais serviços seguem o Sistema de Informação de Arquivos Abertos [OAIS] que define o processo de arquivamento em termos de consumo, monitoramento e reutilização de dados.

Consumidor de Dados

Para os fins deste Grupo de Trabalho, um Consumidor de Dados é uma pessoa ou um grupo acessando, usando, e potencialmente executando passos pós-processamento nos 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.

Formato de Dados

O Formato de Dados é definido como uma convenção específica para a representação de dados; por exemplo, a maneira em que os dados são codificados e armazenados para utilização em um sistema de computação, possivelmente constrito por um tipo formal de dados ou um grupo de padrões.

De: Digital Humanities Curation Guide

Preservação de dados

A Preservação de Dados é definida pela Aliança pelo Acesso Permanente à Rede 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 plano de gerenciamento de dados com foco no planejamento da preservação e nos metadados.. 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 atores.

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.

Proveniência de dados

Proveniê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 proveniência de dados é um metadado que permite que os provedores de dados passem detalhes sobre o histórico de dados aos usuários.

Qualidade de dados

A qualidade de dados é habitualmente definida como “aptidão para uso” para uma aplicação específica ou um caso de uso.

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) [VOCAB-DCAT]

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 terminais diferentes. Exemplos de distribuições incluem um arquivo CSV para download, uma API ou um feed RSS.

De: Data Catalog Vocabulary (DCAT) [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. Marcas temporais de data são associadas a cada mensagem e as mensagens podem ser associadas a uma pessoa ou submetidas anonimamente.

De:Semantically-Interlinked Online Communities (SIOC) and the Annotation Model [Annotation-Model]

Para compreender melhor por que uma anotação foi criada, um Esquema Conceitual [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 inéditos ou abertos.

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, JSON [RFC4627], Turtle [Turtle] e HDF5.

Licenciamento

Um licenciamento é 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 token, tal como uma aba de idioma, que é passada 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 [LTLI].

Dados Inteligíveis por máquinas

Dados inteligíveis por máquinas são dados em formato padronizado que podem ser lidos e processados automaticamente por um sistema computacional. Documentos tradicionais de processamento de palavras e formato de documento portátil (PDF) são facilmente lidos por humanos, porém normalmente são complicados para interpretação e manipulação por máquinas. Programas tais como XML, JSON, HDF5, RDF e CSV são formatos legíveis por máquinas.

Adaptado da Wikipedia.

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 introduzido pelo 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

Dados sensíveis

Dados sensíveis são quaisquer dados ou metadados designados de uso limitado e/ou destinados a públicos limitados. Podem incluir dados pessoais, dados corporativos ou governamentais. Maus tratos a dados sensíveis podem levar a danos a indivíduos ou organizações.

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 uniformes, 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

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.

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 largamente 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

10. Dados sobre os Desafios da Web

Esta seção não é normativa

O diagrama seguinte resume alguns dos principais desafios enfrentados ao publicar ou consumir dados na Web. Estes desafios foram identificados a partir do documento Casos de Uso e Requisitos do DWBP [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 do 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 licenciamento de dados
  • Reuse
  • Trust
Fornecer informações sobre a proveniência dos dados
  • Reuse
  • Comprehension
  • Trust
Fornecer informações sobre a qualidade dos dados
  • Reuse
  • Trust
Fornecer um indicador de versão
  • Reuse
  • Trust
Fornecer histórico de versionamento
  • Reuse
  • Trust
Utilizar URIs constantes como identificadores de conjuntos de dados
  • Reuse
  • Linkability
  • Discoverability
  • Interoperability
Utilizar URIs constantes como identificadores dentro dos conjuntos de dados
  • Reuse
  • Linkability
  • Discoverability
  • Interoperability
Designar URIs para versões e séries de conjuntos de dados
  • Reuse
  • Discoverability
  • Trust
Utilizar formatos de dados padronizados e inteligíveis por máquinas
  • Reuse
  • Processability
Utilizar representações de dados de localidade neutra
  • Reuse
  • Comprehension
Fornecer dados em formatos múltiplos
  • Reuse
  • Processability
Reutilizar vocabulários preferencialmente padronizados
  • Reuse
  • Processability
  • Comprehension
  • Trust
  • Interoperability
Escolher o nível correto de formalização
  • Reuse
  • Comprehension
  • Interoperability
Fornecer download em massa
  • Reuse
  • Access
Fornecer subconjuntos para conjuntos de dados extensos
  • Reuse
  • Linkability
  • Access
  • Processability
Utilizar a 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 justificativa para dados não disponíveis
  • Reuse
  • Trust
Disponibilizar dados por meio de uma API
  • Reuse
  • Processability
  • Interoperability
  • Access
Utilizar padrões da Web como a base para as APIs
  • Reuse
  • Linkability
  • Interoperability
  • Discoverability
  • Access
  • Processability
Fornecer a documentação completa para sua API
  • Reuse
  • Trust
Evitar modificações que quebrem sua API
  • Trust
  • Interoperability
Preservar os identificadores
  • Reuse
  • Trust
Avaliar a cobertura do conjunto de dados
  • Reuse
  • Trust
Coletar feedback de consumidores de dados
  • Reuse
  • Comprehension
  • Trust
Disponibilizar feedback
  • Reuse
  • Trust
Enriquecer dados por meio da geração de novos dados
  • Reuse
  • Comprehension
  • Trust
  • Processability
Fornecer apresentações complementares
  • Reuse
  • Comprehension
  • Access
  • Trust
Fornecer feedback ao editor original
  • Reuse
  • Interoperability
  • Trust
Seguir os termos de licenciamento
  • Reuse
  • Trust
Citar a publicação original
  • Reuse
  • Discoverability
  • Trust

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

REUTILIZAÇÃO

Todas as Boas Práticas

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

Este 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 sobre a proveniência dos dados

Utilizar representações de dados de localidade neutra

Citar a publicação original

R-MetadataDocum

Fornecer metadados

Reutilizar vocabulários preferencialmente padronizados

R-MetadataMachineRead

Fornecer metadados

Fornecer metadados descritivos

Fornecer informações de licenciamento de dados

R-MetadataStandardized

Fornecer metadados descritivos

Reutilizar vocabulários preferencialmente padronizados

R-LicenseAvailable

Fornecer informações de licenciamento de dados

Seguir os termos de licenciamento

R-LicenseLiability

Fornecer informações de licenciamento de dados

Seguir os termos de licenciamento

R-ProvAvailable

Fornecer informações sobre a proveniência dos dados

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

Citar a publicação original

R-QualityMetrics

Provide data quality information

R-DataMissingIncomplete

Fornecer informações sobre a qualidade dos dados

R-QualityOpinions

Fornecer informações sobre a qualidade dos dados

Coletar feedback de consumidores de dados

Disponibilizar feedback

Fornecer feedback ao editor original

R-DataVersion

Fornecer um indicador de versão

Fornecer histórico de versão

R-UniqueIdentifier

Utilizar URIs constantes como identificadores de conjuntos de dados

Utilizar URIs constantes como identificadores dentro dos conjuntos de dados

Designar URIs para versões e séries de conjuntos de dados

Fornecer subconjuntos para conjuntos de dados extensos

Utilizar padrões da Web como a base para as APIs

R-Citable

Utilizar URIs constantes como identificadores e conjuntos de dados

Designar URIs para versões e séries de conjuntos de dados

Fornecer subconjuntos para conjuntos de dados extensos

Citar a publicação original

R-FormatMachineRead

Utilizar formatos de dados padronizados inteligíveis por máquinas

Utilizar a negociação de conteúdo para fornecer dados que estejam disponíveis em formatos múltiplos

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

R-FormatStandardized

Utilizar formatos de dados padronizados e inteligíveis por máquinas

R-FormatOpen

Utilizar formatos de dados padronizados e inteligíveis por máquinas

R-FormatLocalize

Utilizar representações de dados de localidade neutra

R-GeographicalContext

Utilizar representações de dados de localidade neutra

R-FormatMultiple

Fornecer dados em formatos múltiplos

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

R-QualityComparable

Reutilizar vocabulários preferencialmente padronizados

Escolher o nível correto de formalização

R-VocabOpen

Reutilizar vocabulários preferencialmente padronizados

R-VocabReference

Reutilizar vocabulários preferencialmente padronizados

Escolher o nível correto de formalização

Avaliar a cobertura do conjunto de dados

R-AccessBulk

Fornecer download em massa

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 justificativa para dados não disponíveis

Preservar os identificadores

R-SensitivePrivacy

Fornecer uma justificativa para dados não disponíveis

R-SensitiveSecurity

Fornecer uma justificativa para dados não disponíveis

R-APIDocumented

Utilizar padrões da Web como a base para as APIs

Fornecer a documentação completa para sua API

Evitar modificações que quebrem sua API

R-PersistentIdentification

Evitar modificações que quebrem sua API

Preservar os identificadores

R-UsageFeedback

Coletar feedback de consumidores de dados

Disponibilizar feedback

Fornecer feedback ao editor original

R-DataEnrichment

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

Fornecer apresentações complementares

R-TrackDataUsage

Fornecer feedback ao editor original

Citar a publicação original

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. Devemos agradecimentos especiais aos colegas Andrea Perego, Dan Brickley, Linda van den Brink e Jeremy Tandy.

Este documento beneficiou-se da colaboração de muitos membros do Grupo de Trabalho em Dados Espaciais na Web. 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 efetuadas desde a versão anterior::

C. Referências

C.1 Referências Informativas

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