dg:Sobre: mudanças entre as edições

De Documentação
 
Linha 15: Linha 15:
Os dados brutos (fontes originais), por serem arquivos grandes e de baixa demanda, são mantidos em "discos frios" e armazenamento externo seguro. Seus metadados, todavia, são mantidos no ''git'' da respectiva jurisdição.
Os dados brutos (fontes originais), por serem arquivos grandes e de baixa demanda, são mantidos em "discos frios" e armazenamento externo seguro. Seus metadados, todavia, são mantidos no ''git'' da respectiva jurisdição.


=== Coleta periódica ===
=== Coleta persistente ===
Em situação de coleta periódica há garantia de atualização, através de um ''Service Level Agreement'' (SLA) implícito ou explicito, e através de uma API padronizada. O [https://en.wikipedia.org/wiki/Web_Feature_Service padrão WFS] equivale a um "''download'' fresquinho a todo momento", e garante a coleta padronizada das colunas desejadas (já filtradas), mesmo depois de alterações no servidor de origem.
Em situação de coleta periódica há garantia de atualização, através de um ''Service Level Agreement'' (SLA) implícito ou explicito, e através de uma API padronizada. O [https://en.wikipedia.org/wiki/Web_Feature_Service padrão WFS] equivale a um "''download'' fresquinho a todo momento", e garante a coleta padronizada das colunas desejadas (já filtradas), mesmo depois de alterações no servidor de origem.



Edição atual tal como às 08h54min de 11 de março de 2024

Dg-logo-draft1.png
Documentação integrante do
projeto Digital-guard
Países: AR, BR, CO, CM, CL, PE, SR, VE, UY.


Página que descreve o projeto Digital-guard, seus produtos e serviços.

O presente projeto, batizado de Digital-guard/Preserv, consiste no núcleo de software e metadados do projeto de preservação digital de fontes primárias de dados, organizados e mantidos pelo Instituto ITGS.

Preservação dos dados primários

A responsabilidade sobre os dados é dividida entre o Instituto ITGS e a curadoria local de uma jurisdição, tipicamente um país. A jurisdição BR, por exemplo, é relativa ao Brasil e seu repositório git é o preserv-BR.

As curadorias locais selecionam quais dados devem ser preservados e quais os critérios mínimos de qualidade para que um pacote de dados possa ser incorporado ao acervo de preservação.

Os dados brutos (fontes originais), por serem arquivos grandes e de baixa demanda, são mantidos em "discos frios" e armazenamento externo seguro. Seus metadados, todavia, são mantidos no git da respectiva jurisdição.

Coleta persistente

Em situação de coleta periódica há garantia de atualização, através de um Service Level Agreement (SLA) implícito ou explicito, e através de uma API padronizada. O padrão WFS equivale a um "download fresquinho a todo momento", e garante a coleta padronizada das colunas desejadas (já filtradas), mesmo depois de alterações no servidor de origem.

A maturidade digital de uma fonte primária depende da sua capacidade de se atualizar periodicamente e sem custo, ou seja, através de padrões tais como WFS. Apesar de não serem alvo original da AddressForAll, o assunto foi retomado na issue #186 do Preserv-BR. Características:

  • Tem um URL Persistente (PURL) confiável, dispensando a preservação digital periódica (apenas amostras de valor jurídico para a licença).
  • Tem uma API padronizada, tipicamente WFS.
  • Oferece um SLA para a estimativa consistente de "período de recoleta".

PS: tecnicamente a coleta periódica, por exemplo Openaddressess.io, pode ser implementada com make_conf, o inverso é que não é válido.

Coleta efêmera

São eventos que dependem da iniciativa de alguém "solicitar e buscar os dados", tipicamente por e-mail. No caso de oferta via Web, na situação de "coleta efêmera" não há garantia de durabilidade do endpoint nem do padrão estrutural adotado.

A maior parte dos dados brutos obtidos pela AddressForAll foram advindos de coleta efêmera. Ainda assim existe o pontencial de recorrência, do doador repetir doações com dados mais atualizados e dentro do mesmo esquema. Com voto de confiança nos doadores e seu pontencial de recorrência a AddressForAll instituiu o make_conf, que garante a simplicidade e baixo custo de repetição dos eventos de coleta efêmera. Características:

  • Não tem endpoint ou, quando existe, não é um URL Persistente (PURL) confiável, requerendo preservação digital de cada coleta (para garantia de reprodutibilidade da comprovação jurídica da licença).
  • Não tem API ou download padronizado, tipicamente e-mail.
  • Não oferece um SLA para coleta periódica, nem sequer para a próxima coleta.

Repositórios de produtos

Os dados de diversas fontes são comparados estatisticamente e consolidados pela infraestrutura do Instituto ITGS. Os resultados finais da consolidação são dados confiáveis, oferecidos ao público como "versão teste" (testing) e "versão estável" (stable). São de responsabilidade apenas do Instituto, mas o controle de versões é mantido com a mesma divisão de jurisdições que as fontes.

As versões stable são mantidas em repositórios git atualizados periodicamente. Eventualmente os repositórios git serão segmentados em biênios ou triênios, conforme volume de dados e atualização da jurisdição, evitando sobrecarga do git. Os repositórios recebem nomes com a sintaxe digital-preservation-{jurisdição}-stable{anoInicial}. Por exemplo digital-preservation-BR-stable2020 é o git de preservação dos produtos estáveis da jurisdição Brasil iniciado em 2020.

Operando as eclusas de entrega de dados

A cada curadoria local existe um ou mais técnicos responsáveis que justamente assumem a responsabilidade pela integridade dos dados e dão a garantia de que os dados e metadados fornecidos são consistentes e tem origem numa doação de dados realizada pela entidade detentora dos direitos de uso, e portanto cessionária da licença de uso aberta que acompanha os dados.

Os metadados garantem a rastreabilidade tanto da fonte como da licença fornecida. São metadados de proveniência, conforme a estrutura ilustrada abaixo:

Dg-PackModel.png

A entrega de dados brutos pode ser realizada arquivo por arquivo ou "em lote", ambas pelo técnico responsável devidamente autenticado. A entrega em lote é realizada por protocolo SFTP, no ambiente apelidado de Eclusa.

Todo o workflow e garantia de geração de hash é efetuado pela Eclusa.

Eclusa123-ico.png

Códigos-fonte da Eclusa e demais softwares

Ver src.

Ligações externas