W3C Escritório Brasil - Blog

DADOS NA WEB? ESTÁ AQUI COMO FAZER.

por Phil Archer | Versão original em inglês, publicada no Blog do W3C

Quero uma revolução.

Não política, e certamente não violenta, mas uma revolução.

Uma revolução na forma como as pessoas pensam sobre a maneira como os dados são publicados na Web, abertos ou não. Aqui é onde eu costumo começar a falar sobre as pessoas usando a Web como um pendrive glorificado. Ou seja, usar a Web para não fazer mais do que transferir dados de A para B de uma forma que poderia ser facilmente alcançada, colocando-a em um pendrive e enviando-o através do correio.

Fotografia de uma vara do pendrive ajustou-se no cartão de um bibliotecário

Crédito da foto: Rosie Sutton

A Web é muito mais do que isso. Para citar a Arquitetura da World Wide Web, é: “… um notável espaço de informação de recursos inter-relacionados, crescendo através de idiomas, culturas e mídia”. É a conectividade de ideias e fatos entre pessoas que são desconhecidas umas às outras, que é tão emocionante e que tem profundas implicações.

“Existem diversas maneiras de publicar dados na Web, porém até hoje não existia um padrão, um conjunto de práticas capazes de guiar e facilitar o trabalho, tanto para os publicadores, quanto para os consumidores de dados”
Newton Calegari

Mas como fazê-lo direito? Como Rebecca Williams, da GovEx, que trabalhou no data.gov, twittou recentemente: “olhar para ‘portais de dados abertos’ para reunir suas melhores práticas em metadados e licenciamento é andar para trás, pois quase todos estão fazendo errado.” Eu não diria que estão quase todos fazendo errado, mas é verdade que há necessidade de ter uma referência para saber como fazê-lo direito.

Que é a a Recomendação das Boas Práticas para Dados na Web (DWBP).

Levou 4 anos para ser publicada, desde o planejamento do Workshop, até a criação do Grupo de Trabalho, para o que realmente é o escopo e firmando o relacionamento com o Projeto Share-PSI (financiado externamente), para aperfeiçoar um conjunto de 35 Boas Práticas, as quais são passíveis de ação sem serem excessivamente prescritivas.

“Um excelente conjunto de Boas Práticas bem pesquisado e claramente escrito.”
Terence Eden, HM Government

O primeiro é o conceito mais básico de todos: fornecer metadados. Parece bobagem, e pode-se argumentar que se você está publicando dados na Web e não fornece metadados, então você provavelmente está muito interessado que ninguém encontre os dados publicados, muito menos alguém vá usá-los. A Boa Prática (BP) 9 diz “Use URIs persistentes como identificadores de conjuntos de dados” e a BP 10 diz “Use URIs persistentes como identificadores dentro de conjuntos de dados”. Na minha opinião, esses dois estão no centro da diferença entre usar a Web como um pendrive glorificado e usá-la como um espaço de informação global. O Relatório de Implementação mostra muitos exemplos disso, desde as Compras Públicas do Governo Federal até o Projeto de Drogas Conectadas (Linked Drug’s project) da Universidade Metodista da Macedônia St Cyril (Macedonia’s St Cyril and Methodius University), assim como a API do Museu da Guerra de Auckland (Auckland War Museum) e o Projeto Acropolis do Reino Unido.

Fotos dos Benefícios: Reuso (Reuse), Compreensão (Comprehension), Conexão (Linkability), Descobrimento (Discoverability), Confiança (Trust), Acesso (Access), Interoperabilidade (Interoperability), Processamento (Processability)

Reuso (Reuse), Compreensão (Comprehension), Conexão (Linkability), Descobrimento (Discoverability), Confiança (Trust), Acesso (Access), Interoperabilidade (Interoperability), Processamento (Processability)

Cada uma das BPs é classificada de acordo com um ou mais dos benefícios acima.

Há Boas Práticas sobre assuntos que você provavelmente esperaria, como proveniência e licenciamento de dados, e outras menos óbvias como enriquecimento e arquivamento de dados. Estes são assuntos cujo escopo é enorme, assim, o documento de Boas Práticas para Dados na Web deve servir como base para publicar e consumir dados na Web.  No W3C, outros trabalhos estão em andamento, por exemplo, a padronização do ODRL para permissões e obrigações dos dados legíveis por máquina, assim como o Grupo de Trabalho de Boas Práticas para Dados Espaciais na Web, cujas Boas Práticas estão sendo construídas com base no DWBP. Há sempre mais a dizer – e há sempre maneiras diferentes de trabalhar.

“Grande trabalho – um recurso extremamente útil.”
Jeremy Tandy, Met office

As Boas Práticas para Dados na Web não prescrevem o uso de qualquer tecnologia em particular, além dos princípios básicos da Web. Cada BP tem um resultado pretendido, como a BP 14 “O máximo de usuários possível será capaz de usar os dados sem primeiro ter que transformá-lo em seu formato preferido.” Ou a BP 23 “Os desenvolvedores terão acesso programático aos dados para uso nas suas próprias aplicações, os quais serão atualizados sem exigir esforço por parte dos consumidores. Os aplicativos da Web poderão obter dados específicos consultando uma interface programática.” Assim, cada Boa Prática oferece possíveis abordagens para a implementação com alguns exemplos. Se você conseguir o mesmo resultado desejado com uma tecnologia diferente, vá em frente, você ainda está seguindo as melhores práticas.

“O entendimento entre os publicadores e consumidores de dados é fundamental. Sem esse acordo, os esforços dos publicadores de dados podem ser incompatíveis com o desejo dos consumidores”
Caroline Burle

O Grupo de Trabalho de Boas Práticas para Dados na Web foi concebido, no seu Charter, não apenas para criar um conjunto de Boas Práticas, mas para ajudar a promover um ecossistema de compartilhamento de dados. Parte disso é abordada em dois vocabulários, um para descrever o uso de um conjunto de dados (Dataset Usage Vocabulary) – através do uso em uma aplicação, citação no trabalho de outra pessoa etc. – e outro para descrever a qualidade dos dados (Data Quality Vocabulary). A qualidade é raramente um fato objetivo, mas o vocabulário fornece um quadro em que as declarações sobre a qualidade podem ser feitas.

DWBP não é apenas sobre dados governamentais. GS1, a instituição que está por trás dos códigos de barras de produtos do mundo, contribuiu para o trabalho e já o alavancou em sua proposta GS1 SmartSearch. No mundo da pesquisa científica, o Laboratório Nacional do Noroeste do Pacífico (Pacific Northwest National Laboratory), está colocando em prática o trabalho em sua publicação sobre conjuntos de dados de simulação climática na Federação da Rede do Sistema Terrestre (Earth System Grid Federation), no Arquivo de Dados Atmosfera para Elétrons (A2e) e em seu Portal (DAP). Os Laboratórios Nacionais Los Alamos e Lawrence Berkeley também estão usando o documento DWBP para melhorar a forma como os dados são publicados na Web. É importante salientar que para dados de pesquisa, as Boas Práticas para Dados na Web do W3C estão totalmente alinhadas com os princípios da FAIR (FAIR Data Principles).

“A Web destaca-se como um meio de compartilhamento de dados, porém, nem sempre esses dados podem ser facilmente descobertos, acessados e processados. O uso das Boas Práticas para Dados na Web é fundamental para alavancar o compartilhamento de dados na Web, uma vez que garante o fácil acesso e a reutilização dos dados.”
Bernadette Lóscio

É sempre encorajador quando você ouve outras pessoas se referindo ao seu trabalho e o DWBP teve várias menções no Workshop Descrições Inteligentes e Vocabulários Mais Inteligentes (Smart Descriptions e Smarter Vocabularies – SDSVoc), realizado no final do ano passado (relatório sairá em breve, eu prometo). E nós tivemos elogios de muitas pessoas. Gostaria de terminar observando duas características incomuns do Grupo de Trabalho. Primeiro, as três chairs e duas dos três editores do grupo são mulheres. Em segundo lugar este foi o primeiro W3C WG que teve uma participação tão forte do Brasil.
Foi um privilégio trabalhar com um grupo tão extraordinário de revolucionários de todo o mundo.

Foto de quatro pessoas em frente um banner que diz Face to Face São Paulo

Conheça os editores do DWBP & equipe de contato do W3C: (da esquerda para direita) Newton Calegari, Caroline Burle, Phil Archer, Bernadette Lóscio

Como participar de um Grupo de Trabalho do W3C: nossa experiência como editores do Data on the Web Best Practice Working Group

Por: Bernadette Lóscio; Caroline Burle; Newton Calegari

Introdução

O Consórcio World Wide Web (W3C) é um consórcio internacional no qual organizações filiadas de diferentes perfis, desde universidades a grandes players de tecnologia, trabalham em conjunto com a comunidade e a equipe do W3C para fomentar e desenvolver padrões para a Web.

Para o desenvolvimento dos padrões, são criados Grupos de Trabalho, em inglês Working Groups (WG), os quais devem estar associados a uma atividade do W3C (ex: Data Activity). Na fase de criação do WG é responsabilidade de um dos membros da equipe do W3C, o Team Contact, definir a direção estratégica daquele Grupo de Trabalho. Durante o desenvolvimento dos trabalhos, o Team Contact coordena a comunicação ao atuar como interface entre o(s) Chair(s), os Membros do Grupo, outros Grupos de Trabalho e a Equipe do W3C.

A coordenação do Grupo de Trabalho é exercida por um ou mais Chairs, o quais têm a função de facilitar o consenso entre os participantes, além de organizar a pauta das reuniões semanais e enviar por email à lista do grupo. Além disso, devem garantir a participação dos membros, assim como o bom andamento dos trabalhos junto aos demais participantes, conforme explica Joseph Reagle neste texto.

Todo Grupo de Trabalho começa com uma declaração, o Charter, que descreve o escopo do WG, as entregas, os critérios de sucesso e o tempo de duração previsto para entregar a recomendação que será um padrão para a Web. Assim que o WG é criado, após a aprovação do Charter pelos membros do W3C, os participantes podem se inscrever para colaborar com o desenvolvimento daquele padrão. A documentação tem início na Wiki, que pode ser editada por qualquer participante daquele Working Group.

Qualquer documento que será uma recomendação do W3C, e se tornará um padrão para a Web, é construído colaborativamente pelos participantes do Working Group.

A escrita também é colaborativa e sempre há Editores cuja função é contribuir com as discussões e com o conteúdo, deixar o texto coerente de acordo com as resoluções do grupo, coeso e, em última instância, são responsáveis pelo conteúdo daquele documento.

Para participar efetivamente dos Grupos de Trabalho, é preciso ser filiado ao W3C. Dessa forma, as pessoas designadas pelas instituições filiadas ingressam nos grupos que têm interesse e passam a ter responsabilidades perante ao WG. As responsabilidades vão desde participar das reuniões virtuais semanais e das presenciais, chamadas Face to Face, até participar ativamente do processo, com cumprimento de tarefas e contribuições com as resoluções daquele WG. Há a possível barreira do idioma, pois o processo — documentação e reuniões — é todo em inglês, mas é um “inglês internacional” e nem todos são nativos, o que facilita a comunicação.

É importante destacar que qualquer pessoa pode contribuir com o desenvolvimento dos padrões, pois os Grupos de Trabalho, podem receber contribuições externas, as quais devem ser respondidas pelos editores de cada WG. Além disso, todo o processo é documentado na Web.

Com base na nossa experiência como editores do Data on the Web Best Practices, descrevemos abaixo o processo de participação, as regras e as ferramentas usadas pelos membros do W3C para colaborar com o desenvolvimento da Web, de modo que atinja o seu potencial máximo.

Reuniões

Reuniões semanais

Há reuniões semanais que são coordenadas pelos Chairs do WG, que devem enviar a agenda com a pauta do que será discutido e resolvido com a antecedência de 24h à reunião.

Face to Face

As reuniões Face to Face ocorrem em geral duas vezes ao ano, dependendo da disponibilidade dos membros do WG participarem. É uma reunião que dura dois dias e o trabalho é bastante intenso, com o objetivo de solucionar o máximo de Issues e trabalhar ativamente no desenvolvimento da Recomendação. Normalmente, umas das reuniões ocorre durante o TPAC, a Plenária Técnica do W3C, e a outra um dos membros se disponibiliza a organizar.

Issues e Actions

As Issues são questões levantadas por membros do grupo ou têm origem em contribuições externas ou de membros do próprio grupo, que devem ser resolvidas pelos participantes durante as reuniões semanais ou pela lista de email. Já as Actions são tarefas que os participantes assumem e que possuem alguma relação com o desenvolvimento daquela recomendação.

Proposals e Resolutions

Após solucionadas as Issues, para documentar as soluções são feitas — em geral durante as as reuniões — Proposals (Propostas) que após votadas transformam-se em Resolutions (Resoluções). As Resolutions deverão ser incorporadas ao documento pelos editores.

O consenso

Parte importante do processo de construção dos padrões para a Web é o consenso entre os participantes de cada Working Group, chamado de A Arte do Consenso. Isso significa que cada resolução é votada durante a reunião semanal, mas caso alguém vote contra, aquela resolução não é aprovada até que todos os participantes estejam de acordo e para isso seguem as discussões até que se chegue a um consenso.

Regras

Participação ativa

Ao ingressar em um Working Group, o participante assume que concorda com as regras de participação do W3C, dentre as quais consta a participação ativa nas reuniões, a contribuição com o documento, de forma a se disponibilizar e cumprir as ações designadas dentro do prazo estipulado.

Comunicação ativa

A comunicação entre os participantes do WG ocorre por meio da lista de email, assim como durante as reuniões. Toda comunicação é documentada e pública. Além disso, há uma lista de email para comunicação externa aos membros do grupo, pela qual qualquer pessoa pode enviar sugestões e se comunicar com os membros daquele WG.

Entrega de produtos

O Charter de cada WG tem uma lista de entregas chamada Deliverables, as quais são responsabilidade de todos os participantes. Existem diferentes tipos de Deliverables. Pode ser uma Nota, cujo processo ocorre somente pela aprovação dos membros do WG. Ou uma Recomendação, que será um padrão para a Web, cujo processo de aprovação exige a revisão de todos os membros representantes do W3C, do Advisory Committee.

Ferramentas

Há algumas ferramentas importantes usadas pelos Working Groups para viabilizar a comunicação e o desenvolvimento colaborativo dos padrões para a Web:

WebEx

É a ferramenta usada para as reuniões virtuais. Os participantes se conectam pelo link estabelecido para aquela reunião e ativam o microfone e áudio para se comunicar.

IRC

É uma ferramenta de comunicação utilizada durante as reuniões do Working Group para registrar a interação entre os participantes. No início de cada reunião, um dos participantes será eleito o scribe e será responsável por registrar, no IRC, todas as discussões que acontecem durante a reunião. Ao final da reunião, são gerados os Minutes, que armazenam todas as anotações feitas durante a reunião e podem ser vistos como a ata da reunião. Assim, cada participante deve estar sempre conectado à Internet, de preferência por um computador, para se comunicar também pelo IRC.

Conta com um robô chamado Zakim, que facilita a geração dos Minutes de cada reunião ao registrar as anotações, identificar os participantes e facilitar saber quem está na fila para falar.

Além disso, o IRC conta com a facilidade de registrar a ordem das falas, ao adicionar no IRC o “q+”, por exemplo, o participante indica que gostaria de falar, facilitando, assim, a organização da reunião e o cumprimento da pauta previamente agendada.

Github

É uma ferramenta colaborativa de controle de versões, na qual há diferentes repositórios referentes aos grupos de trabalho e atividades do W3C.

Utilizamos o repositório do DWBP para organizar todo o trabalho em torno dos documentos. O documento de Boas Práticas foi escrito em HTML e utilizando a biblioteca ReSpec para se adequar ao padrão visual das recomendações e especificações do W3C.

Além disso, permite aos usuários fazerem comentários sobre o texto ou o código e respondê-los por meio da própria ferramenta.

Wiki

É a principal ferramenta usada atualmente pelo W3C para documentar os arquivos do WG. É colaborativa, portanto, qualquer participante do WG pode criar uma página ou atualizar o conteúdo existente.

Lista de email
É o principal meio de comunicação dos participantes do WG, usada para trocar mensagens sobre o trabalho do grupo entre os próprios participantes, assim como continuar discussões iniciadas durante as reuniões.

Também é o canal oficial de comunicação dos Chairs com o grupo para agendar as reuniões com 24h de antecedência.
Além disso, é usada para receber colaborações externas de outros membros do W3C, ou de qualquer pessoa interessada em contribuir com aquela recomendação.

Código de Conduta

Há um Código de Ética e Conduta Profissional que deve ser cumprido pelos membros do W3C e participantes dos Working Groups.

Conclusão

O desenvolvimento dos padrões para a Web é realmente colaborativo e pode ter a participação ativa dos membros filiados ao W3C, mas também de qualquer pessoa interessada em contribuir.

Como todo o processo é aberto e documentado na Web, basta se familiarizar com as regras e as ferramentas para contribuir com a evolução da Web.

Participar do desenvolvimento da Web de forma ativa, contribuindo com as atividades de um Working Group que faz os padrões para a Web com responsabilidade, ética, respeito aos outros participantes e sempre em busca do consenso é extremamente gratificante.

*Esse texto foi originalmente publicado no Medium Revista Web

Que tal definirmos princípios de Governo Aberto?

Por:
Caroline Burle
Laila Bellix
Jorge Machado

Governo aberto possui inúmeras definições. Articulando transparência, participação social, accountability (prestação de contas) e inovação tecnológica, esse conceito e sua prática tem ganhado, cada vez mais, destaque na agenda das políticas públicas. A riqueza de interpretações pode gerar expectativas e frustrações entre os que participam de processos de governo aberto e distanciar aqueles que poderiam estar envolvidos nesses processos. Por ser tratado por diferentes áreas do conhecimento, distintos atores e contextos políticos e culturais, é importante questionarmos: afinal, o que é governo aberto? Quais são os seus princípios?

Do ponto de vista dos principais organismos que lidam com a temática, governo aberto está atrelado, sobretudo, ao fomento às políticas de transparência e seus temas correlatos, bem como à participação da sociedade no ciclo das políticas públicas. Nessa perspectiva, para alguns atores, é fundamental destacar a accountability e o combate à corrupção como eixos estruturais e, de modo geral, a inovação tecnológica como transversal às demais políticas. Esse levantamento pode ser visto na Tabela 1 da pesquisa* “Qual conceito de Governo Aberto? Uma aproximação aos seus princípios.”, que busca traçar novas perspectivas para essa agenda.

No entanto, há temas transversais, de grande importância, que não são claramente incluídos nessas definições de governo aberto, tais como gênero, diversidade, inclusão, linguagem e acessibilidade. A inclusão desses temas, permitiria dialogar melhor com as metas dos Objetivos de Desenvolvimento Sustentável (ODS ou Agenda 2030) e com declarações internacionais sobre direito das mulheres, minorias e com pautas relacionadas com a defesa dos direitos humanos. Além disso, entendemos ser necessário conceituar participação social, incluir os dados abertos como componente básico e assumir a colaboração e a cocriação como um método para a construção de governos abertos.

De forma resumida, propomos aqui um conjunto de princípios norteadores de um conceito de governo aberto mais claro e objetivo, ao mesmo tempo que abrangente e inclusivo. A ideia é que eles possam servir de referência para governos, sociedade civil, empresas e agências internacionais discutam e elaborem suas políticas.

Proposta de Princípios para o Governo Aberto

Princípio Descrição
1. Participação efetiva A participação é incentivada e inclui informar, consultar, envolver e empoderar cidadãos e organizações sociais.
2. Transparência e responsabilidade Governos devem ativamente prestar contas de todos seus atos e assumir a responsabilidade pública de suas ações e decisões.
3. Dados abertos Devem ser disponibilizados dados abertos, completos, primários, desagregados, atuais, com permissão para sua utilização e de acordo com os padrões internacionais para publicação de dados na Web.
4. Abertura e reutilização de informação pública A informação pública deve circular para atingir seu pleno potencial. É priorizado o uso de licenças livres, que permitam a reutilização das informações.
5. Acesso e simplicidade Sempre que possível, utiliza-se linguagem simples e de fácil entendimento.
6. Colaboração e cocriação. Práticas e políticas são concebidas de modo a estimular a colaboração e a cocriação em todas as etapas de processos.
7. Inclusão e diversidade Há atenção à diversidade e à inclusão. Mulheres, deficientes, minorias e /ou vulneráveis estão incluídos. A atenção inclui o uso da linguagens, tecnologias e metodologias apropriadas para incluir as minorias.

Não esperamos com tal proposta encerrar uma discussão tão importante como essa, mas sim fazer uma provocação sobre princípios fundamentais com os quais a agenda deve dialogar. Desse modo, por um lado, que se traduza em mudanças mais efetivas a forma como se governa e, por outro lado, que atraia novos atores para essa promissora agenda.

Este artigo foi publicado originalmente no Blog da Parceria para Governo Aberto (OGP), em 22 de novembro de 2016, e escrito por:

Laila Bellix
Prefeitura de São Paulo
Faculdade Paulista de Serviços Social (FAPSS)
la_bellix@hotmail.com(link sends e-mail)
@laelab

Caroline Burle S. Guimarães
W3C Brasil
Centro de Estudos sobre Tecnologias Web (Ceweb.br) do NIC.br
carolburlesg@gmail.com(link sends e-mail)
@carolburle

Jorge Machado
Universidade de São Paulo
Co:Laboratório de Desenvolvimento e Participação (COLAB) – USP
machado@usp.br

*O paper completo “Qual conceito de Governo Aberto? Uma aproximação aos seus princípios.” está disponível em: https://goo.gl/1fRLli.

 

Melhores práticas: Dados Na Web – #4 Forneça metadados com informações estruturais

E chegou a vez da quarta melhor prática que vai ser recomendada no documento de Melhores Práticas para Dados na Web, que ainda é sobre metadados.

BP4: Forneça metadados com com informações estruturais

 

Forneça metadados que descrevam o esquema e a estrutura interna dos datasets que você vai distribuir.

O fornecimento de informações sobre a estrutura interna de uma distribuição é essencial para outros que desejem explorar ou consultar o conjunto de dados. Fornecer metadados com informações estruturais também ajuda as pessoas a compreender o significado dos dados.

Metadados- Medialab

Metadados- Medialab Prado – Imagem retirada de https://flic.kr/p/b3bxSv

Resultado esperado:

Humanos serão capazes de interpretar o esquema de um conjunto de dados, bem como os software agents serão capazes de processar automaticamente estas informações.

Possível Implementação

Mas o que são metadados sobre a estrutura?

Metadados com informações estruturais que humans podem ler facilmente geralmente pfornecem propriedades ou nomes das colunas do esquema do dataset. Já dados com informações sobre a estrutura que são legíveis por máquina podem ser fornecidos em documentos separados, ou embedados dentro do próprio documento. A documentação do Tabular Metadata, do JSON-LD, do XML-SCHEMA ou do Datacube apresenta explicações completas e alternativas para uso na descrição da estrutura dos seus datasets.

Exemplos de uso desses metadados:

Legíveis por máquina:

John usou o Modelo para dados Tabulares e Metadados na Web para a publicação do CSV (dataset) sobre paradas de ônibus (stops-2015-05-05.csv). Veja como foram escritos os metadados para as estruturas dos dados no exemplo abaixo:

 




{
	"@context": ["http://www.w3.org/ns/csvw", {
		"@language": "en"
	}],
	"url": "http://data.mycity.example.com/transport/dataset/bus/stops-2015-05-05.csv",
	"dc:title": "CSV distribution of stops-2015-05-05 dataset",
	"dcat:keyword": ["bus", "stop", "mobility"],
	"dc:publisher": {
		"schema:name": "Transport Agency of MyCity",
		"schema:url": {
			"@id": "http://example.org"
		}
	},
	"dc:license": {
		"@id": "http://opendefinition.org/licenses/cc-by/"
	},
	"dc:modified": {
		"@value": "2015-05-05",
		"@type": "xsd:date"
	},
	"tableSchema": {
		"columns": [{
			"name": "stop_id",
			"titles": "Identifier",
			"dc:description": "An identifier for the bus stop.",
			"datatype": "string",
			"required": true
		}, {
			"name": "stop_name",
			"titles": "Name",
			"dc:description": "The name of the bus stop.",
			"datatype": "string"
		}, {
			"name": "stop_desc",
			"titles": "Description",
			"dc:description": "A description for the bus stop.",
			"datatype": "string"
		}, {
			"name": "stop_lat",
			"titles": ["Latitude"],
			"dc:description": "The latitude of the bus stop.",
			"datatype": "number"
		}, {
			"name": "stop_long",
			"titles": "Longitude",
			"dc:description": "The longitude of the bus stop.",
			"datatype": "number"
		}, {
			"name": "zone_id",
			"titles": "ZONE",
			"dc:description": "An identifier for the zone where the bus stop is located.",
			"datatype": "string"
		}, {
			"name": "stop_url",
			"titles": "URL",
			"dc:description": "URL that identifies the bus stop.",
			"datatype": "string"
		}],
		"primaryKey": "stop_id"
	}
}

Para um exemplo desse mesmo tipo de metadados com dados legíveis por humanos, veja esta página.

Para ter certeza de que está fazendo uso da 4a melhor prática, verifique sempre se os metadados do dataset estão em formato que humanos consigam interpretar. Confira se os metadados incluem informações sobre a estrutura dos seus datasets em formatos que sejam legíveis por máquina e sem erros de sintaxe, de preferência 🙂

Mais uma vez, precisamos do seu feedback!

Se quiser comentar ou melhorar esse post, pode também sugerir mudanças direto no Github, eu ficarei muito feliz em receber pull requests 🙂

Para acessar outros posts da série, acesse o acervo no Blog! Ou, assine os feeds do website!

Lembrando que esse post reproduz parte de uma especificação do W3C traduzida e que por causa disso, está sob a mesma licença para documentos do W3C. O importante é: a reprodução é livre, desde que citada a fonte.

 

Melhores práticas: Dados Na Web – #3 Forneça metadados com parâmetros de localidade

Continuando a série de posts que comecei aqui sobre o documento do grupo do W3C do qual sou co-chair, o WG DWBP, vou comentar traduzindo a terceira melhor prática.

BP3: Forneça metadados com parâmetros de localidade

 

Forneça metadados com parâmetros de localidade, ou seja, que descrevem data, hora e formatos de número, bem como linguagem em que os dados estão publicados.

Exzemplo de imagem de localização

Exemplo de imagem de aplicativo que utiliza metadados de parâmetros de localidade para identificar funções para o usuário. Retirado de: https://flic.kr/p/68xJNx

Fornecer parâmetros de localidade ajuda humanos e aplicações de computador a funcionarem com precisão na hora de interpretar dados que identificam datas, moedas e números que podem parecer semelhantes, mas têm significados diferentes em diferentes localidades. Por exemplo, o ‘date’ 4/7 pode ser lido como 07 de abril ou 04 de julho, dependendo de onde os dados foram criados. Da mesma forma € 2.000 é ou dois mil euros ou uma representação de dois Euros com zeros em excesso. Tornando o local e linguagem explícita você dá a chance dos usuários descobrirem quais são os dados e a que se referem, interpretando-os de acordo com normas locais. Isso também tem o mesmo efeito sobre os serviços de tradução automática.

Resultado esperado:
Os seres humanos e os agentes de software vão poder interpretar o datasets que contem datas, horas, moedas,  números etc, com precisão. 

Possível Implementação

Alguns exemplos de parâmetros de localidade são:

  1. A língua (s) do conjunto de dados;
  2. Os formatos utilizados para valores numéricos, datas e hora.A versão legível por máquina dos metadados pode ser fornecida de acordo com o vocabulário recomendado pelo W3C para descrever conjuntos de dados, ou seja, o catálogo para vocabulários de dados, ou VOCAB-DCAT.

Veja o exemplo abaixo que traz metadados de localidade:

O dataset abaixo traz dados das paradas de ônibus (stops-2015-05-05) com a inclusão de metadados de parâmetros de localidade. A propriedade dct:language é utilizada para declarar as linguagens nas quais um dataset está publicado. Se o dataset está disponível em múltiplas linguagens, use múltiplos valores para esta propriedade. A propriedade dct:conformsTo é utilizada para especificar o padrão adotado para formato de data e hora.

 


:stops-2015-05-05
      a dcat:Dataset ;
      dct:title "Bus stops of MyCity" ;
      dcat:keyword "transport","mobility","bus" ;
      dct:issued "2015-05-05"^^xsd:date ;
      dcat:contactPoint <http://data.mycity.example.com/transport/contact> ;
      dct:temporal <http://reference.data.gov.uk/id/year/2015> ;
      dct:spatial <http://www.geonames.org/3399415> ;
      dct:publisher :transport-agency-mycity ;
      dct:accrualPeriodicity <http://purl.org/linked-data/sdmx/2009/code#freq-A> ;
      dcat:theme :mobility ;
      dcat:distribution :stops-2015-05-05.csv ;
      dct:language <http://id.loc.gov/vocabulary/iso639-1/en> ;
      dct:language <http://id.loc.gov/vocabulary/iso639-1/pt> ;
      dct:conformsTo <http://www.iso.org/iso/home/standards/iso8601.htm> ; 
.

Aqui você confere um exemplo com esse tipo de metadados em formato legível por humanos.

Antes de publicar seus dados, tenha a certeza de que os metadados incluem informação sobre os parâmetros de localidade em formato que seja legível por humanos. Além disso, cheque também se o dataset tem informação sobre localidade em formato legível por máquinas. Isso é importante para permitir a integração de produtos que utilizam estes dados em múltiplas plataformas (aplicativos, sites web, redes sociais), facilitando na entrega de dados ao usuário consumidor.

Precisamos do seu feedback!

Se quiser comentar ou melhorar esse post, pode também sugerir mudanças direto no Github, eu ficarei muito feliz em receber pull requests 🙂

Para acessar outros posts da série, acesse o acervo no Blog!

Lembrando que esse post reproduz parte de uma especificação do W3C traduzida e que por causa disso, está sob a mesma licença para documentos do W3C. O importante é: a reprodução é livre, desde que citada a fonte.

 

 

Melhores práticas: Dados Na Web – #2 Forneça Metadados! #UmaPorDia

Ontem saiu o post sobre a Primeira Melhor Prática, que é “Forneça Metadados”. A segunda melhor prática do documento Melhores Práticas para Dados na Web, produzidas pelo WG DWBP, comento hoje.

 

BP2: Forneça metadados descritivos

 

Forneça metadados que descrevem as funcionalidades em geral dos datasets e distribuições.

Fornecer informação descritiva sobre os datasets permite que os user agents descubram automaticamente os datasets disponíveis na Web, além de permitir aos humanos entender a natureza do dataset e suas distribuições.

Resultado esperadoFazendo isso os humanos serão capazes de interpretar a natureza dos dados no dataset e suas distribuições. Além disso os software agents vão descobrir automaticamente os datasets e suas distribuições.

Possível Implementação

Metadados descritivos podem incluir as seguintes funcionalidades de um dataset:

  • O título e a descrição do dataset
  • Palavras-chave que descrevem o conteúdo
  • A data da publicação do dataset
  • A entidade responsável por tornar os dados disponíveis
  • O ponto de contato sobre o dataset
  • A cobertura geográfica do dataset
  • O período temporal que o dataset cobre
  • os temas ou categorias de um determinado dataset

Metadados descritivos podem incluir as seguintes funcionalidades de uma distribuição:

  • O título e a distribuição da distribuição
  • A data da publicação da distribuição
  • o tipo de mídia da distribuição

A versão legível por máquinas dos dados descritivos pode ser fornecida utilizando algum vocabulário recomendado pelo W3C, feito específicamente para descrever datasets. Por exemplo o Data Catalog Vocabulary. Ele fornece um framework para descrever no qual datasets podem ser descritos como entidades abstratas.

Veja o exemplo abaixo que traz dados legíveis por máquinas:

Ele mostra como utilizar o Data Catalog Vocabulary(DCAT) para fornecer dados que possam ser lidos por máquina para o dataset sobre paradas de ônibus (stops-2015-05-05). O dataset tem uma distribuição em .csv (stops-2015-05-05.csv) que também é descrita utilizando o >Data Catalog Vocabulary(DCAT).O dataset está classificado sobre o domínio representado pela URI relativa “mobilidade”.
Este domínio pode ser definido como parte de um set de domínios identificados pelos temas da URI. Para descrever ambos os conceitos e os conceitos do esquema, John utilizou o SKOS. Para expressar frequência de atualização, uma instância das “Content-Oriented Guidelines”, desenvolvidas como parte do vocabulário do W3C “Data Cube” foi utilizada. John escolher descrever a cobertura espacial e temporal do dataset usando URIs do Geonames e o Interval dataset, do data.gov.uk, respectivamente.

:stops-2015-05-05
a dcat:Dataset ;
dct:title "Bus stops of MyCity" ;
dcat:keyword "transport","mobility","bus" ;
dct:issued "2015-05-05"^^xsd:date ;
dcat:contactPoint <http://data.mycity.example.com/transport/contact> ;
dct:temporal <http://reference.data.gov.uk/id/year/2015> ;
dct:spatial <http://www.geonames.org/3399415> ;
dct:publisher :transport-agency-mycity ;
dct:accrualPeriodicity <http://purl.org/linked-data/sdmx/2009/code#freq-A> ;
dcat:theme :mobility ;
dcat:distribution :stops-2015-05-05.csv ;
.

:mobility
a skos:Concept ;
skos:inScheme :themes ;
skos:prefLabel "Mobility"@en ;
skos:prefLabel "Mobilidade"@pt
.

:themes
a skos:ConceptScheme ;
skos:prefLabel "A set of domains to classify documents" ;
.

:stops-2015-05-05.csv
a dcat:Distribution ;
dct:title "CSV distribution of stops-2015-05-05 dataset" ;
dct:description "CSV distribution of the bus stops dataset of MyCity" ;
dcat:mediaType "text/csv" ;
.

Aqui você pode também dar uma olhada em um exemplo de metadados descritivos direcionados ao entendimento de humanos.

Viu? A segunda melhor prática do documento também não é um bicho de sete cabeças. Na verdade, a prática do uso de metadados descritivo é promessa de ganho ao longo do tempo, uma vez que, quanto mais metadados, quanto mais ricos eles são e quanto mais padronizados, mais fácil de utilizá-los para fazer cruzamentos e leituras dos mesmos.

Só lembrando que o grupo precisa do seu feedback sobre as práticas, implementações, exemplos e também os vocabulários produzidos pelo grupo. Se você quiser, pode comentar aqui ou mandar um e-mail para o grupo com suas considerações.

 

Precisamos do seu feedback!

Se quiser comentar ou melhorar esse post, pode também sugerir mudanças direto no Github, eu ficarei muito feliz em receber pull requests 🙂

Lembrando que esse post reproduz parte de uma especificação do W3C traduzida e que por causa disso, está sob a mesma licença para documentos do W3C. O importante é: a reprodução é livre, desde que citada a fonte.

 

 

Melhores práticas pra Dados Na Web: Forneça Metadados! #UmaPorDia

Na semana passada eu publiquei um post falando que ia comentar uma Melhor Prática por dia, do documento de Melhores Práticas para Dados na Web, produzidas pelo WG DWBP.

Pois bem, hoje é dia da primeira:

BP1: Forneça Metadados

Os metadados podem ser considerados etiquetas que ajudam as máquinas e pessoas a identificar do que se trata e o que tem dentro dos datasets. Para entender porque eles são necessários, imagine um depósito do Wall Mart cheio de caixas empilhadas com produtos para vender. Agora, imagine que a Web é o interior da loja e você é o encarregado de colocar tudo nas prateleiras, organizando por tipo de produto. Pra otimizar o seu trabalho, os encarregados de empilhar as caixas no depósito deixaram tudo etiquetado, identificando o conteúdo de cada caixa, evitando que você tenha que abrir tudo para ver o que tem dentro antes de começar a arrumar. Pois bem, esses encarregados que etiquetaram tudo deixaram metadados pra você.

Assim fica fácil entender porque fornecer metadados quando colocar seus dados na Web é tão importante!

Forneça metadados para que humanos e aplicações de computador possam ler

Fornecer metadados é importante quando se publica dados na web porque publicadores de dados e consumidores de dados podem não se conhecer. Por causa disso é preciso prover informação que ajude humanos e computadores a entenderem os dados publicados, assim como outros importantes aspectos que podem ser descritos usando metadados.

Metadata is a note love to the future

“Metadados são um recado de amor pro futuro – foto de https://flic.kr/p/digHTN – Creative Commons 2.5 Licence”

Resultado esperado

Humanos poderão entender os metadados, assim como aplicações de computador – especialmente os user agents, serão capazes de processa-los.

Possível Implementação

Para dados que voê quer que humanos leiam, você pode fornecer metadados como parte de uma página HTML ou prover metadados em um arquivo-texto em separado.

Para dados legíveis por máquina, você pode utilizar um formato de serialização, tipo Turtle ou JSON ou pode embedar no html usando o HTML-RDFAou JSON-LDSe múltiplos formatos forem publicados separadamente, eles devem vir da mesma URL usando negociação de conteúdo (ou conneg) e ficar disponíveis em URIs diferentes, diferenciadas pela exptensão do nome do arquivo. A Manutenção de múltiplos formatos fica melhor se você puder gerar cada formato “on the fly” se baseando numa fonte única de metadados.

Além disso, quando você quiser tornar disponível dados sobre datasets para máquinas, é bom que você use padrões que já existem ou vocabulários que muitos outros publicadores já usam. Por exemplo, os termos do Dublin Core Metadata (DCMI), chamados de DCMI Metadata Terms e o Data Catalog Vocabulary

Só lembrando que o grupo precisa do seu feedback sobre as práticas, implementações, exemplos e também os vocabulários produzidos pelo grupo. Se você quiser, pode comentar aqui ou mandar um e-mail para o grupo com suas considerações.

 

 

Precisamos do seu feedback!

Se quiser comentar ou melhorar esse post, pode também sugerir mudanças direto no Github, eu ficarei muito feliz em receber pull requests 🙂

Lembrando que esse post reproduz parte de uma especificação do W3C traduzida e que por causa disso, está sob a mesma licença para documentos do W3C. O importante é: a reprodução é livre, desde que citada a fonte.

 

 

Melhores práticas pra Dados Na Web #UmaPorDia

Publicação de Dados Na Web

Faz 3 anos que fui ao Workshop que o W3C promoveu sobre Dados na Web, em parceria com o Open Data Institute, em Londres. De lá pra cá (2013-2016) muita coisa aconteceu no mundo dos dados, incluindo a entrada forte de tecnologias de mineração de dados e técnicas de deep learning aplicadas à interfaces Web, na coleta e tratamento de dados. O que não mudou foi a relevância que a Web tem, e sempre vai ter, nos ciclos de dados abertos, estejam eles focados em negócios ou transparência.

Durante esse tempo, o Brasil tomou a frente do processo de padronização de Melhores Práticas para Dados na Web, em um grupo de trabalho cuja criação derivou do que aconteceu nesse workshop em Londres, entre outras ações. O escritório do W3C no Brasil articulou ativamente a participação de brasileiros e por isso eu divido a tarefa de chair do grupo com Hadley Beeman, do governo britânico; e Deirdre Lee, da Irlanda (que esteve na Webbr2015). O W3C Brasil liderou a edição do documento, tendo como editoras a Bernadette Loscio, da UFPE & Caroline Burle, do Ceweb; e o editor Newton Callegari, também, do Ceweb. Além disso, participaram, a convite do escritório, o grupo de universidades brasileiras participantes do programa de fomento a pesquisa do escritório.

O resultado?

Três novos candidatos a padrões: o documento Melhores práticas para dados na web (Best Practices para Dados na Web), que é um documento; e mais dois vocabulários, que tem o status de notas do grupo: um de qualidade de dados (data quality vocab) e um de uso de dados (data usage vocabulary).

Os documentos estão em fase de revisão final antes de virarem candidatos à recomendação. Nesse estágio o grupo, em um esforço colaborativo de atender às necessidades de quem está com a mão na massa, pede a contribuição de todos aqueles que tem como objetivo colocar seus dados na Web, revisando os documentos e sugerindo melhorias nos mesmos.

Pra facilitar o processo de revisão e ajudar todo mundo a entender o documento principal do grupo, vou escrever aqui no Blog do W3C uma série de posts sobre cada Best Practice, publicando com a hashtag #UmaPorDia. Vou começar na segunda-feira, dia 30 de maio de 2016- fique ligado!

Precisamos do seu feedback!

Primeiros rascunhos do grupo de Pagamentos na Web: padrões para Web Payments

A digitalização dos valores que trocamos diariamente é um fato que já esta consumado na sociedade da informaçao. Ainda, segundo pesquisa da Gartner, espera-se ao final de 2016 o valor de 617 bilhões de dólares circulando na Internet. A quantidade de dados disponíveis, como consequência direta da digitalizaçao dos canais bancários e de troca de valores, entretanto, apresenta características que são disruptivas e que precisam ser adequadamente endereçadas para que os impactos sociais e econômicos se dêem em ambiente de uma Internet livre e aberta para todos.

Please Pay Here 3-14-09 19

O W3C, com os grupos de Web payments, tem como missão tornar os pagamentos feitos pela Web mais seguros e fáceis de se realizarem. Para tal, o grupo tem discutido vários aspectos relacionados ao ecossistema de pagamentos digital, que tem como características desde a autenticação até a confirmação de pagamento em tempo real, desafios que o Interest Group e o Working Group têm tentado resolver com novas especificações e orientações.

O grupo de Web Payments do W3C publicou, em Abril de 2016, os primeiros drafts resultantes do trabalho do grupo, que se baseou todo nos documentos de Use Cases e Arquitetura, elaborados pelo Interest Group. Pra tal, o Working Group está documentando fluxos de pagamento reais, documentados no documento Payments Flow, utilizando como base para o trabalho casos reais de empresas como Paypal, Apple, Facebook, Netflix, entre outras.

Desde a segunda reunião presencial do grupo, que aconteceu em fevereiro de 2016 na sede do Google, em San Francisco, os especialistas vem trabalhando nos seguintes documentos:

Esta especificação descreve uma API web pra permitir que sites que vendem coisas na Internet aceitem diferentes métodos de pagamento com a mínima fricção. Com ela os navegadores (user agents) podem facilitar o fluxo de pagamento entre o merchant e o usuário.

Esta especificação define strings para que os componentes do ecossistema de pagamento (retirado dos estudos sobre as possíveis arquiteturas) possam determinar que tipo de parceiros envolvidos no processo de compra suportam quais métodos de pagamento.

Esta especificação descreve os formatos de dados utilizados pela API de requisição de pagamento para suportar pagamento via cartões de crédito ou débito, por exemplo.

Os documentos estão abertos no repositório do grupo e prontos para receberem feedback da comunidade de desenvolvedores e implementadores de soluções para pagamento, especialmente se você pode testar, fazer o deploy ou implementar exemplos com a tecnologia sugerida, nos mostre seus exemplos!

Para facilitar a compreensão do tema, que é complexo e com bastante detalhes específicos da área de pagamentos e finanças, o grupo publicou um FAQ, ainda em inglês.

Se você tem uma pergunta, você pode enviar pelo Github do grupo, que é bem dinâmico:https://github.com/w3c/webpayments/wiki/PaymentRequestFAQ






Novo recurso do Twitter é uma conquista para acessibilidade na Web

Ontem o Twitter anunciou o lançamento de um novo recurso de acessibilidade para dispositivos móveis, que impacta toda a plataforma do serviço. A última versão do aplicativo para Android e IOs tem um recurso para descrição de imagens.

O recurso permite fazer uso de 420 caracteres para descrever a imagem, além dos 140 caracteres que o serviço disponibiliza para cada tweet. Mas como efetivamente isso funciona?

Two screen shots of the composer for Twitter for iOS. The first showing the new Add description button overlayed on a thumbnail in the composer. The second showing the composition of alt text for an image.

Ao selecionar uma foto para publicar, um botão com o texto “Adicionar descrição da imagem” aparece sobre a foto. Essa descrição serve para preencher o atributo ALT da imagem publicada na interface Web. Simples e genial.

O atributo ALT serve para fornecer texto alternativo para uma imagem. Isso é importante pois o texto é exibido caso a imagem não seja carregada ou seja lida por usuários de softwares leitores de tela.

Fiz um teste ontem desse recurso, e o resultado foi bem satisfatório:

Publiquei este tweet com o recurso de descrição da imagem. Ao inspecionar o código da imagem na interface Web do Twitter, o código fica da seguinte forma:

<img data-aria-label-part src=”https://pbs.twimg.com/media/CewYhp4W4AAoLbv.jpg”
alt=”Foto de um bonsai sobre uma superfície de madeira” style=”width: 100%; top: -0px;”>

Esse é um recurso incrível que permite que qualquer pessoa possa descrever as imagens no Twitter. Por utilizar texto que está dentro do atributo ALT, ele permite que pessoas pessoas cegas e de baixa visão que utilizam softwares leitores de tela consigam acessar a descrição da imagem proporcionada pelo próprio usuário.

Outras redes sociais fazem uso do atributo ALT também em suas imagens, mas não com o objetivo de descrever a imagem. O Instagram, por exemplo, usa o texto da legenda da foto repetido dentro do atributo ALT. Parece suficiente, mas não serve muito quando você tem uma foto de um copo de suco derrubado na mesa com a legenda “quem nunca?”.

Como habilitá-lo

O recurso não vem habilitado por padrão no aplicativo. Para habilitá-lo, abra o app do Twitter, vá em configurações e em seguida em acessibilidade. Selecione o checkbox de “Escrever descrições das imagens”. Pronto (pelo menos foi assim que consegui configurar o app no Android, mas creio que em IOs não seja muito diferente).

Apesar de ainda ser um recurso disponível apenas para os aplicativos nativos para Android e IOs, esperamos que em breve ele esteja disponível para a versão Web do Twitter.

Parabéns, Twitter!

PS: Nós também temos que fazer a nossa parte. Utilize esse recurso para descrever imagens da próxima vez que publicar uma foto no Twitter.