[okfn-br] Digest okfn-br, volume 45, assunto 92

Peter Krauss ppkrauss em gmail.com
Quarta Abril 29 17:09:01 UTC 2015 

Oi Neide obrigado por participar dessa "discussão meio nerd" !   :-)

Projetos como o Portico e o pioneiríssimo Gutenberg são iniciativas bem
aparentadas com as de dados abertos...
Acho que o principal elemento de interseção com Open Knowledge é a demanda
por *curadorias*.

Quanto ao PDF (incluindo PDF/A) brincamos aqui que deveria ser "banido"
porque dificulta a recuperação da informação estruturada... Ideologicamente
a OKBr valoriza mais as curadoria focadas em formatos como o EPUB
<https://en.wikipedia.org/wiki/EPUB> (e-books) e o JATS
<https://en.wikipedia.org/wiki/Journal_Article_Tag_Suite> (artigos
científicos)  porque além do layout, a estrutura do conteúdo pode ser
recuperada, e é preservada como informação pública.
A maioria dos *acervos de preservação* (e suas curadorias) nas quais
acreditamos (me corrijam aqui na lista!),
precisa na prática ser "*dual*", deve preservar dois objetos "gêmeos"
simultaneamente, para contemplar os dois objetivos:

* *preservação tradicional*: onde vale toda a sua colocação sobre PDF/A (!);

* *preservação estrutural*: que é mais moderna e contempla a informação
completa, sem distorções por posicionamento (como lembrou o Raniere).

Na área científica os principais exemplos de *acervo de preservação* são o
SciELO (Brasil) e o PubMed Central (EUA),
   https://en.wikipedia.org/wiki/SciELO
   https://en.wikipedia.org/wiki/PubMed_Central

ambos já com acervos "duais" da casa dos milhões de artigos (!), ambos
preservando o conteúdo em objetos JATS (acesso completo à informação) e PDF
(layout e oficial)...
O chato dessa representação "dual" é que realmente não pode haver
disparidade entre o PDF e o JATS... Daí a nossa discussão aqui na lista ter
também tocado no tema "sistemas de XML-Publishing": só eles garantem que o
exatamente o mesmo conteúdo (no caso XML JATS) dê origem às diversas
saídas: PDF, HTML, EPUB e o que mais quiser (ex. relatório de resumos).

Na área jurídica não é diferente: o LexML só vai decolar o dia que as
editoras dos Diários Oficiais gerarem simultaneamente o XML/LexML e o PDF.
Hoje somente o PDF oficial tem "valor de prova" para os juízes, quando
pedem para se demonstrar que uma lei realmente existe.

PS: quanto ao uso do JPEG2000-lossless (sem compressão), como padrão para
acervos de preservação, mesmo SciELO e PMC (PubMed Central) ainda estão
devagar (!), ainda insistem no TIFF... precisamos incentiva-los a usar,
veja por exemplo http://programmers.stackexchange.com/q/195359/84349


Peter




Em 29 de abril de 2015 12:47, Neide De Sordi <nsordi em gmail.com> escreveu:

> Prezados,
>
> Peço desculpas antecipadamente por escrever alguma impropriedade porque
> não estou acompanhando bem a discussão.
>
> EPUB é um formato de arquivo digital padrão específico unicamente para
> e.books.
>
> O PDF-A é o formato adequado para a preservação digital (ações requeridas
> para manter o acesso a materiais digitais além dos limites de falha da
> mídia ou da mudança tecnológica).
>
> Essa questão de preservação é complexa porque, por um lado, queremos
> manter a informação intacta, como ela foi criada e por outro, queremos
> acessá-la dinamicamente e com as mais avançadas ferramentas.
>
> A preservação digital deve ser uma preocupação dos produtores da
> informação e dos responsáveis por grandes acervos de documentos digitais,
> especialmente, dos editores científicos.
>
> Devemos nos preocupar com a obsolescência de formatos. Diversas
> iniciativas estão sendo adotadas pelas universidades e outras instituições,
> como os projetos: PORTICO http://www.portico.org/digital-preservation/ ,
> LOCKSS  www.lockss.org/  w CLOCKSS www.clockss.org/clockss/Home.
>
> O PDF/A é o resultado de um grupo de trabalho liderado por entidades, como
> a Library of Congress, a NARA (National Archives e Records Administration),
> a Adobe, a Xerox, entre outros, e elegeram esse formato para a preservação
> de documentos eletrônicos, que veio a ser homologado como norma ISO
> 19005-1:2005 em Setembro de 2005: o PDF/A-1.
>
> São diversas normas que regulamentam o PDF-A e suas variações: PDF/E para
> engenharia, PDF/X para produção de impressão e PDF/VT para impressão
> transacional e de dados variáveis. PDF/A-2 - Usa JPEG2000 compressão de
> imagem apoio para efeitos de transparência e camadas incorporação de fontes
> OpenType provisões para assinaturas digitais, de acordo com o PDF
> Assinaturas Eletrônicas Avançadas. PDF/A-3 - Permite a incorporação de
> formatos de arquivos arbitrários (tais como XML, CSV, CAD, documentos
> processamento de texto, planilhas e outros documentos) em PDF/A como
> objetos completos arquivados.
>
> Cordialmente,
>
> Neide De Sordi
>
> Em 29 de abril de 2015 09:00, <okfn-br-request em lists.okfn.org> escreveu:
>
>> Send okfn-br mailing list submissions to
>>         okfn-br em lists.okfn.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://lists.okfn.org/mailman/listinfo/okfn-br
>> or, via email, send a message with subject or body 'help' to
>>         okfn-br-request em lists.okfn.org
>>
>> You can reach the person managing the list at
>>         okfn-br-owner em lists.okfn.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of okfn-br digest..."
>>
>>
>> Tópicos de Hoje:
>>
>>    1. Re: dados abertos burilados, num PDF!?... (Raniere Silva)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 29 Apr 2015 08:31:42 -0300
>> From: Raniere Silva <raniere em riseup.net>
>> To: "Grupo de interesse em conhecimento livre no Brasil, especialmente
>>         dados abertos // Open Knowledge discussion list for Brazil"
>>         <okfn-br em lists.okfn.org>
>> Subject: Re: [okfn-br] dados abertos burilados, num PDF!?...
>> Message-ID: <20150429113142.GF23903 em buriti.rgaiacs.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> > *Explicando melhor.*
>> > O Banco Mundial, os órgãos do governo, e dezenas de outros não podem
>> ficar
>> > só na visualização instantânea. Precisam de uma "foto oficial" e deixar
>> > essa foto registrada.
>> > Nas faculdades (teses), nas revistas (artigos), e nos Diários Oficiais
>> > (atos)... Todos precisam de uma versão PDF bem diagramada, que fica
>> > oficialmente registrada.
>> > ... O PDF, neste cenário, é a "a cara do resultado". Sem um bom PDF a
>> > divulgação oficial dos resultados não é boa.
>>
>> Não precisamos de PDF.
>> Infelizmente ainda estamos na transição entre papel e bytes.
>>
>> > Não podemos fugir da demanda por *relatórios PDF bem diagramados:*  a
>> lei,
>> > a tradição, e eventualmente até o bom senso, mandam que se faça assim.
>> PDF
>> > é ainda um "mal" necessário. EPUB ainda está longe de substituí-lo.
>>
>> O "problema" com o EPUB é o mesmo com vários outros padrões
>> e chama-se "problema do ovo e da galinha".
>> Ferramentas para visualizar e editar EPUB não melhoram
>> porque ninguém usa o padrão
>> e ninguém usa porque as ferramentas são ruins.
>>
>> > Quem é programador sabe que "produzir *bom* PDF" não é possível com as
>> > bibliotecas que dispomos em Pythom, PHP, Java e cia.
>>
>> Depende de como você está trabalhando.
>> A conversão de HTML para PDF via web browser muitas vezes não é
>> satisfatório
>> porque seu HTML está "defeituoso", e.g. utilizando tabela para o layout.
>> Se você tiver um HTML enxuto a conversão é aceitável.
>>
>> Se você achar que a impressora nativa do seu web browser não faz um bom
>> serviço,
>> o Pandoc consegue converter HTML para LaTeX, ODT e DOCX que você pode
>> imprimir.
>> Novamente, se seu HTML não estiver enxuto a conversão vai ficar ruim.
>>
>> > Neste link temos contextualizadas as duas únicas soluções baseadas em
>> > padrões abertos, o XSL-FO e o CSS-page,
>> >
>> >     http://stackoverflow.com/q/10641667/287948
>> >
>> > PS: o TeX/LaTeX tem pequena comunidade, bem ativa e fiel, mas não é
>> > recomendação W3C, nem conversa com ecosistemas (X)HTML.
>>
>> Existe várias ferramentas que converte (La)TeX para (X)HTML.
>> A "melhor" é https://github.com/brucemiller/LaTeXML.
>>
>> > Neste link uma sondagem sobre "trabalho de fato" que vinha sendo
>> realizado
>> > no WebKit e no Blink (engine do Chrome),
>> >
>> > https://code.google.com/p/chromium/issues/detail?id=368053
>>
>> AFAIK CSS2 e CSS3 não estão totalmente implementados
>> e vai demorar ou nunca acontecer dos web browser mais populares
>> implementarem ambos os padrões na sua totalidade.
>>
>> > Demandas do dia.
>> >
>> > *DEMANDA1 - Alguém na lista gostaria de ajudar a acompanhar as
>> iniciativas
>> > do Blink e de outros engines rumo ao CSS-page?*
>> >
>> > É o cenário esboçado acima, requer testar as ferramentas que se dizem
>> "boas
>> > diagramadoras". A proposta é poder recomendar para os projetos OKBr
>> > diferentes soluções para diferentes "graus exigência na diagramação". O
>> > foco no CSS-page se justifica pelo ecossistema de padrões abertos
>> > associados.
>>
>> Minha recomendação é escrever em Markdown
>> e utilizar o Pandoc para converter para o formato que precisar:
>> HTML, PDF (via LaTeX), ODT, DOCX.
>>
>> > *DEMANDA2 -  projeto Wiki-do-MEI vai precisar gerar PDFs bonitos para os
>> > MEIs; é com CSS-page, preciso da ajuda de designer com experiência em
>> CSS.*
>> >
>> > O principal exemplo é gerar bonito PDF com os resultados de
>> >     http://www.xmlfusion.org/wiki-do-mei/Atividades
>> >     http://www.xmlfusion.org/wiki-do-mei/Atividades_por_setor
>>
>> Você pode tentar utilizar o Pandoc para isso.
>> Baixa as páginas que deseja em Wiki Markup,
>> só adicionar '?action=raw' no final da URL, sem as aspas,
>> e utilizar o Pandoc para converter no formato que você deseja.
>>
>> Raniere
>> -------------- Próxima Parte ----------
>> Um anexo não-texto foi limpo...
>> Nome: signature.asc
>> Tipo: application/pgp-signature
>> Tamanho: 819 bytes
>> Descrição: Digital signature
>> URL: <
>> http://lists.okfn.org/pipermail/okfn-br/attachments/20150429/2da4ca59/attachment-0001.sig
>> >
>>
>> ------------------------------
>>
>> Subject: Legenda do Digest
>>
>> _______________________________________________
>> okfn-br mailing list
>> okfn-br em lists.okfn.org
>> https://lists.okfn.org/mailman/listinfo/okfn-br
>> Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
>>
>>
>> ------------------------------
>>
>> Fim da Digest okfn-br, volume 45, assunto 92
>> ********************************************
>>
>
>
> _______________________________________________
> okfn-br mailing list
> okfn-br em lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/okfn-br
> Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
>
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20150429/50d8bcf8/attachment-0005.html>

Mais detalhes sobre a lista de discussão okfn-br