cdn.media.ccc.de/.../wikidatacon2019-1035-eng-Data_import_process_overview_hd.mp4

Boa tarde a todos.

Bem vindos ao nosso painel GLAM.

Antes de começarmos,
tenho dois anúncios a fazer.

Em primeiro lugar, usem exaustivamente
o Etherpad para tirar notas, por favor.

O segundo é direcionado
para a nossa audiência em casa,

ou onde quer que estejam.

Se tiverem alguma questão,

podem sempre escrever no Etherpad,

e os nossos anjos na sala
darão seguimento.

Decidimos que, para o painel deste ano,

depois de ver
todas as contribuições que foram fazendo,

que deveríamos focar-nos
no papel de Wikidata

dentro dos ecossistemas de dados

para ir além
dos projetos de Wikimedia atuais.

O que está perfeitamente alinhado

com a estratégia
da nova Fundação Wikimedia.

E, hoje, temos quatro oradores.

Três mais um.

Por isso, quero pedir-lhes
para subirem ao palco,

para que vos possa apresentar.

Temos a Susanna Ånäs.

Ela é activista
pelo conhecimento livre há muito tempo

e está envolvida em vários WikiProjects.

E vai fazer hoje o relatório
do projeto em cooperação

com a Biblioteca Nacional da Finlândia.

Depois temos, ao meu lado, Mike Dickison,

que vai ser o segundo orador.

Ele é curador num museu na Nova Zelândia.

É zoólogo e editor da Wikipedia.

E foi o primeiro Wikipedian
da Nova Zelândia em residência

em 2018 e 2019.

Vai contar-nos
sobre a sua experiência neste papel

e o que está a ser feito
no contexto de trabalho para a Wikidata.

Depois vamos ter Joachim Neubert
vindo do Centro de Informação

para a Economia de Leibniz
em Kiel e Hamburgo.

Esteve a trabalhar para fazer o maior
arquivo público mundial de imprensa

mais acessível ao público,
e está a utilizar a Wikidata para isso.

Eu serei o último a falar.

O meu nome é Beat Estermann.

Trabalho para a Universidade de Berna
de Ciências Aplicadas, na Suiça.

Tenho sido um promotor, há muito tempo, da
OpenGLAM na Suiça e Áustria.

Hoje, falo-vos sobre as minhas atividades
em ligação com o mandato

da Associação
de Representação de Artes Canadiana,

focadas nas artes performativas.

Não principalmente na Wikidata,

mas verão que a Wikidata está a começar
a ter um papel ativo, também ali.

Agora, a maior parte de nós
vai sentar-se por aqui,

e vou dar o palco à Susanna.

Olá, o meu nome é Susanna Ånäs.

Trabalho em part-time
para a Wikimedia Finlândia

como coordenadora para a GLAM

e faço também consultoria
na esfera do conhecimento livre.

Este é um discurso, talvez de,
falar da consultoria e não do part-time.

Tenho estado envolvida em temas

de grupos de dados geográficos,

de...

Bem, fui verificar os termos em Inglês,

tem a ver com uma iniciativa cultural
hereditária do Governo da Finlândia.

Isto tem a ver com nomes de locais

e como são representados

nos diferentes repositórios
no setor da GLAM na Finlândia

e como estão a tentar conciliar
as diferentes fontes de informação

e como estão a informar-se
modelando na Wikidata e outros locais.

Aqui podemos ver as três grandes fontes
de informação para estes locais YSO,

que fazem parte
da ontologia nacional, ontologia geral.

AHAA são os arquivos finlandeses,

Melinda são as bibliotecas finlandesas,

e KOOKOS são os museus finlandeses.

Existem também,
três sistemas de gestão de conteúdo

que são conciliados nesses locais YSO.

Existem, também, intercâmbios
entre a Wikidata a funcionar,

assim como o projeto de nomes
para o Cadastro Nacional de Terrenos.

E existe um terceiro projeto,
o Arquivo de Nomes Finlandês,

que ainda não contribui para isto,

mas existem planos para que o faça.

Um dos assuntos de modelação
principais nesta área problemática

é que existem três tipos
de elementos de nomenclatura

representados neste projeto.

Um deles é o local,
o que tem a localização.

E outro é a nomenclatura,
a toponímia, por exemplo.

Depois, existem as fontes,
que são documentos

dos quais
os dois anteriores podem derivar,

ou, serem suportados.

Os locais YSO,
aqui, no canto superior direito,

verão o mesmo diagrama de novo.

Foca-se maioritariamente nos locais.

O aspecto principal disto
é a Biblioteca Nacional Finlandesa,

e o Projeto Finto.

Existem agora mais de 7,000 locais
em finlandês e sueco

e mais de 3,000 em inglês,

e são CC0 com quem nós licenciámos.

Aqui podem ver o serviço do Finto.

e um local, escolhi Sevettijärvi.

Está agora também relacionado
com o nosso projeto linguístico

com o Skolt Sámi...

É um local no norte longínquo da Finlândia

habitado por Skolt Sámi.

Aqui podem ver o local que pertence a...

Aqui podem ver dados sobre este local.

Podem ver que está ligado à Wikidata,

e também a estes dados cartográficos
nacionais.

Aqui vamos.
E podem ver com mais detalhes, aqui.

Está também hierarquicamente arranjado

dentro deste repositório, para que...

Bem, na realidade,
o local em si não é visto,

mas está por baixo desta municipalidade,

como também da região

e da Finlândia como país
e países nórdicos,

como região fronteiriça.

Aqui podem ver que muitos destes

foram conciliados
com a Wikidata anteriormente

através de Mix'n'Match,
e que existem ainda alguns remanescentes.

Mas mesmo assim o número de nomes
não é assim tão alto.

São menos de 5,000.

E existe este outro repositório

propriedade do Projeto
de Plataforma Geoespacial Finlandês...

Quadros de Nomes de Locais.

Estes são nomes de locais
que estão no mapa Finlandês.

E têm os dados ligados,
licenciados como CC BY 4.0.

800,000 nomes em Finlandês, Sueco
e nas outras três línguas Saami

que existem na Finlândia.

Depois têm dois tipos de entidades.

Outros são locais, e os outros

são nomes de locais, topónimos.

Ambos têm URIs
(identificador uniforme de recurso).

Aqui, por exemplo, o mesmo Sevettijärvi,
primeiro em finlandês,

e depois nas outras três línguas Saami,
bem como os dados geográficos.

Por último, temos mais informação
sobre isso, como o tipo de local, etc.

Aqui, vemos o quadro para o nome do local,
o topónimo, a ter o seu próprio URI.

Desculpem, parece
que não está traduzido para inglês.

Então, as multilínguas
não abrangem o projeto inteiro.

Chegámos ao Arquivo de Nomes Finlandeses.

Este projeto é
do Instituto de Línguas da Finlândia,

que não representa locais,
nem os nomes dos locais,

mas sim a origem disso tudo.

São três milhões de campos
de notas de nomes de locais,

e é um projeto Wikibase.

Estão numa Wikibase, principalmente
em finlandês, mas alguns também em sueco.

Uma espantosa coleção de nomes em Saami,
nos quais estamos bastante interessados.

E estão licenciados em CC BY.

Isto também é um desafio
do ponto de vista da Wikidata.

Mas se houvesse
uma Wikibase local finlandesa,

éramos capazes de trabalhar primeiro neles
dentro desse projeto.

Então, aqui temos uma imagem disso,

que mostra que existe
informação sobre o local, os mapas...

dos mapas
que os colectores usaram inicialmente.

e um quadro que produziram
a partir da informação recolhida.

Aqui está um desses quadros

decomposto nos dados

que está incluído nele.

Eles enviaram
este projeto de dados sincronizados

pelo Helsinki Digital Humanities Lab
and Semantic Computers,

o grupo de computação
da Universidade de Aalto

em conjunto com o Instituto
para as Línguas da Finlândia...

o Names Sampo.

Este é um interface agregado de pesquisa

para várias fontes de nomes.

Aqui conseguem ver que
várias das fontes estão aqui à esquerda

e que podem fazer
vários tipos de visualização

baseados nestes dados.

Tenho trazido esta ideia
de modelação para uma Wikibase local

que poderiamos fazer com estes dados.

Mas, quando entramos
nestas questões de modelação,

como o faremos?

Existem várias formas,
diferentes tradições em cada um deles.

A boa noticia é que podemos
servir línguas minoritárias

com muito pouco esforço.

Então, aqui temos as duas opões básicas:

o modelo SAPO, que é
a Ontologia Finlandesa Espaço-Tempo,

e o modelo Wikidata.

Aqui podem ver que
os itens Wikidata tendem para ser zero.

Idealmente, permanecem sem alteração
com as propriedades modificadas.

Enquanto no modelo SAPO,
estes itens tornam-se novos

quando existe uma modificação,
tal como mudança de área e nome.

Então, aqui,
voltando atrás para esta divisão

entre estas três dimensões diferentes
de locais, nomes de locais.

Devemos colocar estes nomes de locais
em entidades ou propriedades?

A Wikidata usa propriedades,

enquanto este projeto
de cartografia utiliza entidades.

Ou devemos torná-la um lexema?

A Wikidata escolheu
trabalhar com propriedades,

propriedades textuais
para nomes de locais ao invés de lexemas.

Lamento, é o contrário.

Então, os nomes são...

propriedades, não lexemas.

Certo.

E talvez a falha da Wikibase

seja a falta
de formas geográficas dentro disso...

Como a configuração base disso,

para que cada um possa adicionar
mais tecnologia à pilha

de forma a poder utilizar
formas geográficas locais.

O que é realmente preciso
é uma federação

para se conseguir tirar partido
do colectivo da Wikidata.

E penso que terminei. Obrigada.

(orador a rir)

(aplausos)

Está bem.

(orador a falar em maori)

Bem vindos a todos.
O meu nome é Mike Dickison.

Por um ano,

fui o Wikipedista
da Nova Zelândia em residência.

Devem estar a perguntar-se
o que é um Wikipedista em residência.

Porque se forem mesmo procurar o que é,
não existe tal termo, como podemos ver.

É um termo que eu inventei
na proposta de bolsa,

e do qual a fundação
pareceu gostar imenso.

E como tal, avançámos com ele.

Por isso, por um ano,
passei por 35 instituições diferentes,

tive estagiários, e muitas vezes,
dei sessões de treino.

Organizei eventos públicos,
e tentei desenvolver

uma estratégia Wikimedia
para cada um deles.

Foi uma experiência bastante interessante,

e encontra-se uma variedade ampla
de diferentes projetos e pessoas.

Queria tentar falar de alguns
dos diferentes projetos

que lidaram com a Wikidata

de formas interessantes ou talvez,
de formas iluminadas,

que talvez sejam úteis
para as pessoas discutirem.

O projeto foi inicialmente
um projeto Wikipédia, pelo nome,

simplesmente porque era com isso
que as pessoas estavam familiarizadas.

Como tal, organizámos
vários eventos diferentes

em editatonas bem tradicionais,
trabalho para a igualdade de género, etc.

E uma quantidade grande de...[inaudível]

E uma quantidade grande de novos
editores recrutados, bem sucedidos, etc.

Fizemos carregamentos de volume
para o Commons.

Neste caso, existia uma coleção
de mais de 1,000 desenhos originais

feitos por
um ilustrador entomólogo, Des Helmore,

que estiveram parados
dentro de um disco rígido,

à espera de pesquisa durante uns 10 anos.

Conseguimos autorização para os libertar
dentro de uma licença CC BY.

Sabem como é. Vitórias fáceis
para mostrar às pessoas por lá.

Qualquer um pode perceber
várias fotografias dos escaravelhos.

Qualquer um entende workshops dedicadas
a tentar colmatar a igualdade de género.

Mas a Wikidata
é muito mais difícil de vender

a pessoas no setor GLAM,
(galerias, bibliotecas, arquivos e museus)

ou a alguém fora
do nosso movimento tão particular.

Então, comecei
a aperceber-me que a Wikidata

ia ser uma parte cada vez mais importante

de projetos
de Wikipedistas em residência.

À medida que íamos avançando,
tornou-se um componente cada vez maior

do que eu estava a fazer.

E comecei a tentar aprender sozinho
também sobre a Wikidata,

porque estava a aperceber-me
do quão importante era.

Então, este projeto em específico...

O kakapo é um papagaio
neozelandês que não voa.

Trabalhámos com
o Departamento de Conservação,

que tem como trabalho salvar
esta espécie de extinção

e demos a ideia:

"E se, pusessemos
cada um dos kakapos na Wikidata?"

(risos)

E isto até pode parecer ridículo,

mas é, na realidade,
um projeto perfeitamente viável.

Alguns já se encontram inclusivamente lá.

Uma coisa chave a reparar
é que não existem assim tantos kakapos.

Por isso, é uma tarefa fazível.

Existiam 148 quando comecei
e depois um morreu.

E agora tiveram uma temporada
de reprodução excelente até aos 213.

Isto é excelente. É o maior número
de kakapos desde há mais de 50 anos.

Por isso,
isto foi também muito importante.

Isto esteve nas notícias,
todos os dias, na Nova Zelândia.

Cada um que nascia...

(plateia 1) No New York Times.

(Mike) A sério? Oh, que bom.

Sim, foram notícias internacionais.
Toda a gente gosta destas aves.

Mas uma coisa interessante sobre eles

é que, ao contrário
de espécies que são mais numerosas,

cada um dos kakapos tem nome,
um nome único

e um número de bilhete de identidade.

E geralmente tem
uma boa quantidade de dados biográficos

sobre onde e quando nasceram,

quando chocaram, quem foi o pai e a mãe,

quando morreram, se morreram.

Existe, de facto, uma base de dados
do Departamento de Conservação

com esta informação toda.

E um dos mais famosos kakapos
é o Sirocco, claro,

que, como podem ver, foi nomeado
a partir de um vento, nasceu ali.

O Sirocco tem uma conta de Twitter,

com a qual a Wikidata
teve alguns problemas,

porque, aparentemente,
pássaros não podem ter contas do Twitter.

Tenho dúvidas sobre isso.

Ele entrou inclusivamente
na capa de um álbum, e por aí fora.

Por isso existem
múltiplas propriedades disto,

provavelmente um dos mais famosos kakapos.

Abordei o Departamento de Conservação,

"Porque é que não tentamos
fazer isto com os outros todos?"

Então, tiveram de pensar em que
dados biográficos podiam tornar públicos.

E voltaram com uma lista bem curta.

E agora temos, penso eu, 212,
210-- penso que um casal morreu--

kakapos vivos todos eles candidatos.

Só lhes é dado um nome quando
as asas se desenvolvem totalmente.

Enquanto são bebés só têm um código.

Portanto, quando
forem todos adultos, vamos criar

uma Wikidata completa...

a espécie completa estará na Wikidata.

Mas precisamos de encontrar
uma propriedade para DOC ID...

Queria mesmo falar convosco acerca disso.

Devemos usar uma ID específica,

ou devemos encontrar uma ID

que seja válida para todos os indivíduos,
sejam eles aves, plantas ou animais

que forem marcados
em algum projeto de pesquisa científica?

É uma boa questão.

O segundo projeto foi
a Galeria de Arte de Christchurch.

Estão lá algumas pinturas
de Colin MacCahon,

o artista neozelandês
mais famoso na História.

Este é um desenho que ele fez
para o New Zealand School Journal,

patrocinado na altura pelo governo.

Por isso, está atualmente
nos Arquivos da Nova Zelândia

que têm o seu copyright.

Esta é uma situação que não é usual.

Trabalhei com
a Galeria de Arte de Christchurch

que, em conjunto
com a Galeria de Arte de Auckland,

mantêm um site chamado
Find New Zealand artists.

Que tem como função
manter o rasto às posses...

cada instituição que
tenha posses de algum artista neozelandês.

Existem perto de 18,000 artistas
diferentes na sua base de dados,

e a maior parte
com muito pouca informação.

Então, fizemos um tipo de
procura standard de Mix'n'Match.

Exportámos os que tinham
pelo menos a data de nascimento,

ou data de morte,
ou local de nascimento, ou local de morte.

Por isso, não é restringir muito.

E mesmo assim, não fomos capazes
de encontrar a correspondência de alguns,

mas agora já temos perto de 1,500

que correspondem
a artistas conhecidos na Wikidata,

o que é muito bom.

Mas o que foi apelativo para eles...

Este é o website deles,

que, na realidade,
só mantém as ligações para os recursos.

Mas estes dados biográficos,
que mantêm atualmente de forma manual,

para todos os artistas.

E o ato de exportar
e colocar no Mix'n'Match

expôs inúmeras gralhas e erros
nos quais eles não tinham reparado.

E é somente quando começas a
executar coisas [em Excel],

que este tipo de situações aparecem.

E o valor da Wikidata
de repente começou a fazer-lhes sentido

quando eu disse, "Podem simplesmente
carregar essa informação da Wikidata."

Isso fê-los
sentarem-se direitos na cadeira.

Por isso, penso eu,
este é um dos pontos que vende.

Quando têm
este website curado à mão

com 18,000 entradas, cheio de erros
e lhes dizem que existe outra forma,

que podem ter outras pessoas

a fazer a verificação dos factos
e correcção por eles...

é quando eles se apercebem.

E depois anunciei que estava a dar a ideia

que eles "Wikidataficassem"
este caderno de história deles,

dos artistas neozelandeses
em Christchurch nos anos 30,

e que percorressem-- só agora publicado--
e que percorressem cada pessoa singular,

cada ligação, local, exibição e afins.

Mas é um projeto de tamanho gerenciável,
e eles estão excitadíssimos com isso.

Em terceiro lugar, queria mostrar-lhes
o Maori Subject Headings.

Waka é um nome Maori
para um tipo particular de canoa,

uma canoa de guerra.

Na Biblioteca Nacional da Nova Zelândia

existe uma lista de waka,
porque a Biblioteca Nacional

tem atualmente o seu próprio
dicionário de Maori Subject Headings,

escrito em Maori.

Então, lá está definida a waka,

em Maori e Inglês.

Mas também tem muitos termos
de terminologia mais reduzida,

podem vê-los ali na lateral.

Uma típica poderia ser taurapa.

E a definição primeiro em maori,
e depois em inglês.

É o mastro esculpido que podem ver ali.

E, em inglês, deveriam dizer "mastro",

mas não podem
usar a palavra "mastro" para taurapa,

porque taurapa só funciona
para modelos únicos de canoas de guerra.

Por isso, não existe
equivalente em inglês para isso.

E, de repente, apercebo-me
que existe uma ontologia inteira

de termos culturais específicos
e que foram cuidadosamente trabalhados

e verificados pela Biblioteca Nacional
com os Maori.

sendo constantemente adicionados
e melhorados com definições e descrições,

em maori e inglês.

Muito interessante.

De repente, pensei que pudessemos
colocar este lote inteiro na Wikidata...

Maori primeiro e depois
traduzido para inglês, como requisitado.

Seria uma boa mudança, não?

E aqui está a cópia de direitos de autor.

Infelizmente, uma licença de
Atribuição-NãoComercial-SemDerivações.

Por isso, agora
vou ter de iniciar a conversa com eles

sobre o porquê
de terem escolhido essa licença.

Muito possivelmente porque
a conseguiram comprar de Maoris,

que aceitaram sentar-se com eles
e vender esta coisa

só se houvesse uma garantia

de que nenhuma dessa informação pudesse
ser utilizada com propósitos comerciais.

Um dos aspetos frustantes da tarefa

é ir contra este tipo de restrições.

Estas eram as três coisas
que queria trazer à discussão.

Pôr uma espécie inteira
dentro da Wikidata,

O que faz alterar a forma de pensar
de um curador de uma galeria de arte

acerca do valor da Wikidata.

E o que fazemos quando vemos
uma ontologia completa

noutra língua que,
infelizmente, foi presenteada

com uma licença
restritiva da Creative Commons.

Obrigado.

(aplausos)

Olá, chamo-me Joachim Neubert.

Trabalho para a ZBW,

que é o Centro de Informação
Económica em Hamburgo,

como programador de software científico.

Uma das minhas tarefas no ano passado

foi preparar
uma doação de dados para a Wikidata.

E quero deixar o meu relato sobre isto,
das nossas primeiras experiências

de doar metadados
dos Arquivos de Imprensa do Século XX.

Que tenhamos conhecimento,

este é o maior arquivo
público de imprensa do mundo.

Foi reunido entre 1908 e 2005,

e foi conseguido a partir de

mais de 1,500 jornais e periódicos

alemães e também internacionais.

E cobre tudo o que possa ser de interesse

para Hamburgo,

para as pessoas de negócios

que quisessem expandir-se pelo mundo.

Como podem ver, este material
foi trazido de jornais

e colocado em papel,

e depois guardados em dossiers.

Aqui podem ver um pequeno canto
do Arquivo de Pessoas.

Informação similar
foi reunida de empresas,

de tópicos gerais,
de artigos, de toda a gente,

de tudo o que pudesse ser interessante.

Estes dossiers foram digitalizados

até mais ou menos 1949

pelo projeto financiado
pelo DFG de 2004 a 2007.

Como resultado, até agora,
foram 25,000 dossiers temáticos

desta altura.

Isto contém perto de 2 milhões
ou mais de 2 milhões de páginas.

E estão online.

Esta aplicação
desenvolvida na altura pela ZBW,

que agora parece um pouco ultrapassada,

não tão bonita e
que agora é mais um problema.

É uma aplicação que foi construída
arquitecturalmente em Oracle,

construída em ColdFusion,
é executada em servidores Windows,

por isso não é
muito sustentável a longo prazo.

E discutimos se devemos migrá-la

para uma melhor aplicação de dados

ou se devemos dar um passo radical

e por os dados todos em aberto.

Atribuímos uma licença CC0 àqueles dados

e, neste momento,
estamos a mover algumas camadas...

algumas camadas de descoberta...
por isso é uma camada primária de acesso,

para uma web de dados abertos ligada

onde faz mais sentido

pôr alguns metadados na Wikidata.

E para garantir que todas as pastas

das coleções estão ligados à Wikidata,

para que possam ser encontradas,

e que a metadata dessas pastas

seja também transferida para a Wikidata.

De forma a que seja usada aí,
e que seja enriquecida lá, possivelmente.

Podem ser feitas correções a esses dados.

O que ainda é mantido pela ZWB é,
claro, o armazenamento de imagens,

que não podemos pôr de qualquer forma,

ou não podemos dar a respetiva licença

porque são propriedade
dos criadores iniciais.

Mas fazermos tudo
para que sejam accessíveis

por alguns
ficheiros de metadados via DFG Viewer.

No futuro, por manifestos de IIIF.

E vamos preparar algumas
páginas estáticas de entrada

que vão servir de ponto de dados
de referência para a Wikidata,

bem como para colocar dados disponíveis

que não encaixam bem na Wikidata.

Para nós, é migração e
doação de dados à Wikidata

com a nossa infraestrutura costumizada

de endpoint SPARQL, com esses dados,

e que nós utilizámos
com consultas federadas

entre o endpoint e
o Wikidata Query Service

para criar declarações de acordo.

Com [os olhos] concatenados

em consultas de SPARQL
ou transformados via script,

que também geraram referências
para as declarações.

E depois, pô-los em QuickStatements
do código para utilizar online.

Então, isto é o que temos.

Não são coisas simples como
datas de nascimento, mas, desculpem...

mas também declarações complexas

sobre alguns itens já existentes,

como esta pessoa que teve um cargo
de Administração de uma dita companhia

durante este período de tempo,

e referênciada para ser utilizada em...

contexto científico.

A primeira parte desta doação de dados
foi terminada.

O Arquivo de Pessoas
está completamente ligado à Wikidata.

E esta é também
uma ferramenta de informação.

Uma boa parte dos itens
que estavam aqui antes

não tinham referências externas.

E tínhamos mais de 6,000 declarações,

que têm agora fontes
nos metadados deste arquivo.

Bem, esta foi a parte mais simples,

porque pessoas
são facilmente identificadas na Wikidata.

Mais de 90% já existia por aqui,

por isso, podíamos fazer as ligações.

Criámos à volta de 100 itens para estes,

para os que estavam a faltar.

Mas agora, estamos a trabalhar

no resto do arquivo,

particularmente no Arquivo de Tópicos.

Isto quer dizer mapear
um sistema histórico

acerca de todo o mundo,
para a organização de conhecimento,

materializado como manchetes
de um jornal na Wikidata.

Para vos dar uma ideia básica,
o arquivo de Países e Tópicos

está organizado
por uma hierarquia de países

e outras entidades geográficas

que estão traduzidas para inglês,
o que torna isto mais simples.

E para alemão profundamente agrupado..

na classificação dos tópicos
profundamente agrupados

E esta combinação define uma...

...uma pasta.

O que queremos fazer agora é mapear isto

como estrutura para
a Wikidata e trazer dados.

Quero convidar-vos

a juntarem-se a este desafio interessante

em termos de organização de conhecimento.

Este trabalho é seguido
num projeto WikiProject,

e podem segui-lo ou participar nele.

E sim, muito obrigado.

(Aplausos)

Estamos a levar
as artes performativas para a Wikidata.

E estamos a levar as artes performativas
à nuvem de dados aberta ligada,

ao construir
um ecossistema ligado e de dados abertos

para as artes performativas.

E a questão que estou a tentar responder,

e espero que me ajudem
a responder a questões

colocadas à Wikidata e a tudo isso.

Mas deixem-me, primeiro,
começar com as minhas experiências

que aconteceram este ano,

no primeiro semestre do ano,
quando tive o prazer

de trabalhar para a CAPACOA,

que é a Associação Canadiana
de Artes Representativas,

que atualmente lançou um projeto chamado
Iniciativa Para o Futuro Digital Ligado,

para conseguir que o setor inteiro de arte
no Canadá abraçasse os dados ligados.

E fizeram isso com base na observação

que, durante os últimos cinco anos,

a necessidade... o tópico importante
dentro das artes performativas

era o facto dos metadados
não terem qualidade suficiente

e não estarem interligados,
não serem interoperacionais.

E isso foi o porquê
de algumas performances,

alguns eventos, não serem
fáceis de encontrar

pelo Google
e pelos assistentes virtuais, etc.

Portanto, a visão que desenvolvemos juntos

é que queremos ter
uma base de dados de conhecimento

para vários intervenientes ao mesmo tempo.

Observámos então o valor
da rede inteira de artes performativas,

identificámos os intervenientes chave,

observámos os cenários de utilização
que queríamos investigar,

e mapeámo-los na arquitetura global

dessa base de dados de conhecimento,
ou das diferentes plataformas,

que é, obviamente,
uma arquitetura distribuída

e não um grande monólito.

Vou só rever isso por alto

porque temos dez minutos para cada.

Mas acho que temos tempo suficiente
entre hoje e amanhã para aprofundar o tema

se houver alguém interessado nos detalhes.

Começámos a partir da
Rede de Valor das Artes Performativas,

que, curiosamente,
só foi publicada o ano passado.

Somos uns sortudos por termos conseguido
construir a partir do trabalho anterior,

por exemplo, temos a corrente de dados
de valor das artes performativas no meio,

e os vários intervenientes à volta disso.

No total, identificámos
20 grupos de intervenientes

que, depois,
reduzimos para sete grandes categorias

para cada grupo de intervenientes.

Nós como que...

formulámos o tipo de necessidades

que teriam nesse tipo de infraestrutura,

e o que teriam de atingir
se o todo estivesse interligado

e os dados estivessem
acessíveis publicamente.

E assim, podem ver os tipos aqui,

os diferentes tipos são Produção,
depois Apresentação & Promoção,

Cobertura & Reutilização,
Audiências ao Vivo

Consumo Online, Herança,
Educação & Pesquisa.

E, depois de preparar
uma tabela tão grande,

da qual só conseguem ver a primeira parte,

comparámos e demos
uma vista de olhos ao tipo de dados

que estávamos a utilizar pelo quadro

pelos diferentes grupos de intervenientes.

Temos uma base de dados
grande que é comum a todos eles,

e é, na realidade, a área

onde faz muito sentido, na verdade,
cooperar e manter esses...

...guardar esses dados juntos.

Então, quando falamos
de arquitetura da plataforma,

podemos ver que temos aqui 4 camadas.

Em baixo, temos a camada dos dados.

Claro, a Wikidata é parte disto,

como também outras bases de dados,
bases de dados distribuidas

que podem expor dados
por endpoints SPARQL.

Na camada amarela do meio,
temos a camada de semântica.

É a nossa linguagem comum
para descrever as nossas coisas,

para fazer declarações acerca
das artes performativas, da ontologia.

Depois temos uma camada aplicacional

que consiste em vários módulos,
por exemplo, análise de dados,

extração de dados, para que
convertamos dados não estruturados

em dados estruturados...

como podemos apoiar isso
com as ferramentas.

Depois, obviamente,
temos a visualização de dados...

se houver grandes quantidades de dados,
queremos visualizá-los de alguma forma.

E no topo, temos a camada de apresentação,

que é onde
os utilizadores comuns estão a interagir

numa base diária...

motores de busca,
enciclopédias, agendas culturais,

e uma variedade de outros serviços.

Não estamos a começar do zero.

Algum do trabalho já foi feito nesta área.

Vou só citar alguns exemplos de um projeto

em que estive envolvido.

E outras coisas a decorrer também.

E como tal, comecei nesta área

com o Arquivo Suíço
de Artes Performativas.

Até construir uma base de dados
Suiça de Artes Performativas,

criámos uma ontologia
de artes performativas,

que está neste momento
a ser implementada em RDF.

E temos ALI uma base de dados
com quase 60, 70 anos

de história de performances na Suiça.

Portanto, isso é algo
que pode ser construído

e foi transformado em formato RDF.

E havia uma plataforma
onde esses dados podem ser acedidos.

Fizemos também
algumas inserções na Wikidata,

parcialmente a partir da Suiça,

também parcialmente a partir
de institutos de artes performativas.

Por exemplo,
Bart Magnus estava envolvido nisso.

Foi a força motriz por trás disso.

Existem também dados de Wikimedia Commons,

mas que não estão muito bem interligados
com o resto dos nossos metadados.

E, obviamente, ao fazer esta inserção,

também começámos a implementar
partes do modelo de dados Suíço

na Wikidata.

Depois, temos um dos parceiros
de implementação Canadianos

que é a Culture Creates.

Estão a gerir uma plataforma
que tira informação de websites de cinema.

e coloca-a dentro
de um gráfico de conhecimento,

para depois a expôr
a motores de busca e outros dispositivos.

Novamente, tivemos de
implementar e estender isto na ontologia.

E, como podem ver pelo slide,
existem muitos espaços em branco,

mas também existem
algumas sobreposições,

e uma sobreposição importante, obviamente,
é a linguagem partilhada comum,

que nos vai ajudar
a interligar os vários blocos de dados.

O que é também importante, obviamente,

é que estamos a utilizar
a mesma base de registo e certificados.

E isto é uma coisa onde a Wikidata
está a ter um papel importante

ao interligar isso.

Agora, quero partilhar as recomendações

do Comité de Aconselhamento para
Iniciativas Futuras de Ligação de Dados.

Pelo menos
as duas primeiras recomendações.

Então, para os Canadianos,
é agora absolutamente crucial

preencher o seu próprio gráfico canadiano
de conhecimento de artes performativas,

porque, ao contrário do Arquivo Suíço
para as Artes Performativas,

eles não estão a começar com
uma base de dados pré-existente,

mas sim a criá-la do zero.

E é absolutamente crucial haver lá dados.

Em segundo lugar,
como podem ver, vem já a Wikidata.

A Wikidata, pelo Comité de Aconselhamento,

foi vista como complemento à Artsdata.ca,
este gráfico de conhecimento,

e, como tal, devem ser feitos
esforços para contribuir

para a introdução de dados relacionados
com artes performativas.

E isso é onde vamos trabalhar
durante os próximos meses e anos

e é também por isso
que estou aqui também a ver

quem se quer juntar a esse esforço.

Por isso, agora, obviamente,
estamos a dizer que se complementam.

Temos de pensar nos prós e contras

de cada uma das abordagens.

Podem ver aqui uma comparação

entre a abordagem da Wikidata e
a da ligação de dados mais clássica.

Estou disponível para discutir isso
em detalhe convosco

e saber como foram
as vossas experiências com isso.

Mas, para mim, a Wikidata tem vantagens
porque é uma plataforma de crowdsourcing,

e porque é fácil
convidar mais gente para contribuir.

Do lado negativo, obviamente,
temos este problema de falta de controlo.

Os donos dos dados têm de abrir mão
dos seus gráficos, qualidade de dados,

e do que completaram.

É difícil fazer o rastreamento da Wikidata
mesmo que esteja sob o vosso controlo.

Outro forte da Wikidata

é que requer integração imediata
com o gráfico global.

E vocês como que, só o fazem...

como que reconciliam passo por passo
contra outras bases de dados,

que pode ser visto
por alguns como uma vantagem,

mas claro, se estão à procura de
integração e interoperacionalidade,

a Wikidata força-vos
a fazer isso desde o inicio.

E depois, claro, harmonizar
as práticas de modelação de dados

é uma situação em ambos os casos.

Mas pode parecer, no inicio,
mais fácil fazê-lo só no vosso silo,

porque, a certa altura,
acabarão a tarefa

e será uma tarefa
que continuará na Wikidata.

Então, quando chegar à parte de
prioritizar os dados para serem inseridos,

é como as regras que tenho neste momento.

Primeiro que tudo, queremos entender

se está claro ou não quem será
a autoridade em determinada área.

Por isso esses serão dados que terão
de ser geridos de forma partilhada.

E queremos entender onde podemos ver

um potencial elevado
para abordagens crowdsourcing.

Queremos também perceber
se os dados poderão ser reutilizados

no contexto da Wikipedia.

E existe também a esperança
que parte da coordenação internacional

à volta de toda a modelação de dados,
sobre a standarização,

possa mesmo ser feita
diretamente na Wikidata

se não estiver a ser feita noutro local,

porque é como que se forçasse as pessoas
a começar a interagir,

se digerirem os dados na mesma parte.

Queremos focar-nos a seguir
nos registos base e ficheiros de controlo,

porque vão ajudar-nos
a fazer as associações

entre diferentes dados
e vocabulário não controlado

como uma extensão
da ontologia já existente.

Só mais dois slides.

Os próximos passos vão ser
levar a soma de todas as abordagens GLAM

para a Wiki Loves Performing Arts.

Isto significa que estamos
a descrever locais e organizações,

e a colocar os dados na Wikipédia

em formato de infoboxes
e templates de bolhas.

E no outro slide, os outros projetos
que vou seguir chamam-se COST Action

que vamos submeter no próximo ano

à volta do Ecosistema de Dados

Abertos Ligados
para as Artes Performativas.

O COST é um programa europeu
que apoia as actividades de redes,

e os tópicos
a serem abrangidos estão listados aqui.

Dois deles, sublinhei-os...

um deles é a questão federativa
entre a Wikidata

e as abordagens clássicas
de dados abertos ligados.

E a outra, penso eu,
que também é muito importante,

onde temos ainda um potencial enorme,

é implementar campanhas internacionais
para dados suplementares na Wikidata.

E é tudo. Muito obrigado
pela vossa atenção.

Agora, queria chamar
aos meus colegas aqui ao painel.

Se calhar
também lhes poderiam arranjar microfones.

E depois queria...

dar-vos a oportunidade
de colocar questões.

E, obviamente, perguntar aos meus colegas

se têm questões uns para os outros.

Então, temos se calhar,
alguma questão do público?

(plateia 2) [inaudível]

Queria perguntar a cada um de vós

onde colocariam limites,

basicamente, como definem...

quando precisam
de fazer a vossa própria Wikibase

e o que querem colocar na Wikidata?

Por exemplo, isto é
uma delimitação clara do que é visto

por detrás do que colocam [na ordem].

Posso responder primeiro
porque tenho o microfone.

Tenho estado a pensar
que um dos assuntos é a notariedade.

Estou a endereçar isso
num projeto diferente.

Penso que o licenciamento é um deles,

porque podem aplicar os vossos termos
na vossa própria base de dados,

e depois, penso,
onde quer que seja possível.

Depois, o terceiro
é tê-los somente como um ensaio,

preparando-os para tratamento na Wikidata.

Estes são os três assuntos principais
de que me lembro, para já,

mas posso trazer-vos mais.

Para mim, os direitos
serão sempre um assunto.

Se a Biblioteca Nacional
quisesse migrar para a Wikibase,

isso poderia habilitá-los
a continuar a controlar o licenciamento

pelo trabalho que têm feito
com os termos da língua maori.

A base de dados kakapo só contém dados

que o Departamento de Conservação
achou que deveria ser tornados públicos,

mas suspeito que se a virem a funcionar,

poderão tentar utilizar
uma Wikibase privada

para manter a sua própria base de dados,

somente porque
algumas das ferramentas de visualização

que poderão ser aplicadas
podem ser melhores

que a espécie de folha de cálculo de Excel
que têm actualmente.

Bem, penso que isto
depende muito do tipo de dados.

Nós estamos, no Arquivo de Imprensa,
claro, numa posição bastante sortuda,

no sentido em que
isto era material que foi publicado,

foi publicado na altura,

mas foi
bastante dispendioso para publicar.

Isto é muito simples.

Penso que, também, projetos...

e isto é um projeto típico,

foi patrocinado por algum tempo,
depois o patrocinio acabou,

e o que aconteceu aos dados,
é que foram colocados num silo,

sobre um software
que não vai correr para sempre.

Por isso, faz sentido absoluto a meu ver.

Na altura, a Wikidata,
não estava por aqui, mas agora está,

e faz sentido
para os nossos projetos, desde cedo,

discutir a sustentabilidade
no contexto de como podemos colocar isto

num ecossistema maior, como a Wikidata

e discutir isto com a comunidade de dados:

o que será importante e fará sentido
ser adicionado à Wikidata,

e o que fará sentido ser mantido
numa forma proprietária.

Se calhar numa forma mais simples
do que numa aplicação sofisticada,

mas estando disponível
e ligado à nuvem de dados maior

ao invés de investirem muito dinheiro

num qualquer silo que não é sustentável.

Sim, como disse antes
no projeto que apresentei aqui,

existem dualidades entre a Wikidata

e as abordagens clássicas
de dados abertos ligados.

Por isso, não é tanto acerca de
como configurar uma Wikibase privada.

É como um desafio que tivemos
e, claro, na Wikidata

é que, quando tratamos
os nossos próprios dados lá,

também temos de fazer alguma manutenção

de pessoas,
de outras pessoas, na realidade.

Isso pode desencorajar as pessoas.
Também quer dizer que nós trataremos disso

passo a passo.

Por isso, existirá, no momento,
uma base de dados a viver...

de dados abertos ligados
de forma clássica.

Nós estamos a começar
a ligá-los à Wikidata

e é um processo contínuo para encontrar

quais as áreas em que
os dados principais ficarão na Wikidata,

e em que áreas ficarão
realmente noutras bases de dados.

Obviamente, teremos desafios
em relação à sincronização,

como todos temos,

porque esse campo de dados ligados,

onde ainda temos
de negociar em quem confiamos,

ou quem tem a autoridade sobre o quê.

(assistente) Mais questões?

(plateia 3) Obrigada.

Concordo plenamente nesse assunto de...

onde colocar essa fronteira

entre o porquê
de pomos dados na Wikidata,

ou porquê ficarmos com eles,
e criá-los, geri-los e mantê-los

em bases de dados locais
e com que propósitos.

E penso que isso é uma grande discussão

que vai para além da excitação

de colocar dados na Wikidata
porque é público,

porque serve a humanidade, porque...

enquanto existem duas ferramentas fixes.

E as coisas são
mais complicadas na vida real, penso eu.

Bem, fora isso,
é uma discussão interessante.

E depois, isto é outra situação,
ou outro problema que está a ser discutido

neste evento, em diferentes painéis.

Por um lado, temos a nossa base de dados,

qualquer que seja a tecnologia,

e publicamos coisas na Wikidata,

ou criamos o nosso sistema

de criação e gestão de informação

com a tecnologia Wikibase.

E depois, sincronizamos ou assim...
unimos ou outra coisa.

Por isso, é uma questão
de tecnologia que é utilizada,

e do facto de usarmos a Wikidata
apenas para publicar,

ou a infraestrutura
que está por baixo da Wikidata,

para criar e gerir os vossos dados.

Quer dizer, tivemos uma discussão

sobre o painel da Wikibase

e haverá outras discussões aqui,

mas as coisas
estão em níveis diferentes, penso eu.

Talvez [tenham] para essa discussão
sobre a Wikibase ou Wikidata...

Penso ser problemático
estarmos a focar-nos tanto

nesta infraestrutura da Wikibase,
porque existem outras infraestruturas,

como na área das artes performativas.

Temos outra comunidade complementar
que é a MusicBrainz

que tem a sua própria plataforma
que disponibiliza dados abertos ligados.

E, de acordo com o que percebi,

existe acordo,
entre a comunidade Wikidata,

de como não duplicaremos os seus dados...

Não copiaremos todos os seus dados,
mas aceitamos que se complementam.

O que irá acontecer quando começarmos
a integrar esses dados na Wikipédia?

Caixas de informação, por exemplo.

Será que vamos ser capazes
de puxar esses dados directamente

do seu endpoint SPARQL?

Ou vamos ser obrigados a,
como que copiar todos os dados,

e que tipo de processos
estarão envolvidos nisso?

(plateia 3) As discussões
estão abertas, penso eu,

porque, neste evento,
temos ambas as comunidades interessadas...

os interessados na Wikibase,

os que estão interessados na Wikidata,

e os que estão interessados em ambos.

Sim, mas não vamos obrigá-los
a migrar para a Wikibase.

- (plateia 3) Não necessariamente.
- A MusicBrainz não corre na Wikibase.

(plateia 3) Não, só queria dizer
que temos problemas separados,

por vezes relacionados,
por vezes não separados completamente.

E tenho outra questão ou reparo

acerca da gestão de hierarquias
em vocabulários controlados,

como thesaurus, ou como você no Finto.

Tem os locais

nos Cabeçalhos de Assuntos Maori.

Bem, eles têm de lidar com...

a gestão de conceitos na hierarquia.

Qual é o seu parecer, a sua opinião,

sobre a possibilidade de gerir

estes sistemas controlados

de organização
de conhecimento na Wikidata?

Penso que no caso do Finto e locais YSO,

o repositório será uma coleção
de várias fontes, eventualmente.

Por isso, está fluído, de qualquer forma.

Não temos de necessariamente...

bem, eu não represento
a Biblioteca Nacional,

mas nesse possível projeto,

não teríamos de manter uma existente...

ou lutar com uma estrutura existente.

Por isso, nesse sentido,

é uma...

uma área aberta a exploração.

Os Cabeçalhos de Assuntos Maori
têm tendência a colocarem-se idealmente

na estrutura Wikidata,
mas o licenciamento, claro, proibe isso.

Suspeito que,
se o licenciamento fosse diferente

e fossem postos na Wikidata,

assim que alguém decidisse
que não gostava da hierarquia

e começasse a alterar coisas,

haveria imediatamente uma reclamação
das pessoas que trabalharam arduamente

para criar essa estrutura

e ter o consentimento
dos diferentes Maori

que estão na hierarquia corrente.

Por isso, é um assunto
a experimentar e resolver.

Penso que, em termos de
sistemas de organização de conhecimento,

são todos diferentes.

E não tenho a certeza
se seria uma boa ideia

representar diferentes hierarquias
na Wikidata como tal,

mas talvez faça sentido
pensar em sobreposições

de dados.

Para fazer mapeamentos
ao nível de conteúdo.

Por exemplo, como a parceria
ZBW Thesaurus para a Economia.

Este dicionário
tem a sua própria hierarquia,

e, claro, seria possível
projectar a hierarquia

desse dicionário nos conceitos da Wikidata

sem armazenar este tipo de estrutura

como uma estrutura
alternativa dentro da Wikidata,

o que faria uma confusão tremenda.

Penso que devíamos pensar da Wikidata,
também, como uma lista de conceitos

que podem ser ligados
em camadas que estão no exterior,

e que dão outra visão do mundo,

que não precisa de estar
necessariamente dentro da Wikidata.

(assistente) Certo. Mais alguma questão?

Ou então... Sim.

(plateia 4) Joachim, queria só
dar seguimento ao último ponto.

Essas camadas, como imaginadas por si,

seriam mantidas externamente
e de alguma forma integradas

com a Wikidata,
a partir do lado da Wikidata,

ou pensou um pouco mais

sobre como isso poderia ser gerido?

Por acaso, não, não pensei...

Fiz experiências com a ZBW e a Wikidata.

Estava preso aqui à Wikidata.

Mas penso que isto é uma coisa
completamente nova e complexa

e, como tal, aberta a discussão
para conseguir concordância

de fazer essas coisas.

Mas terá de ser visto.

Podemos ouvir mais uma?

(plateia 5) Estava a pensar
no projeto kakapo.

(apresentador anuí)

(plateia 5) Teve algum contratempo
da comunidade Wikidata

sobre ter animais reais
fora desses itens?

Não até agora.

(plateia 5) Alguém ouviu isto antes?

Foi "não até agora" porque
ninguém ouviu isto até agora?

Existe uma pequena discussão,
há já algum tempo...

as pessoas interessadas
neste tipo de coisas na Wikidata.

E parece que todos pensamos
que isso é uma extensão natural,

de ter itens individuais da Wikidata,
até um cavalo de corrida famoso

ou o gato de alguém, que...
está bastante bem modelado.

Imagino que a coisa audaciosa é
pôr uma espécie inteira lá.

Mas penso que seja perfeitamente fazível.

(plateia 5) Não tentem com gatos e cães.

(risos)

(assistente) Penso que
o nosso tempo chegou ao fim.

Muito obrigado por terem participado.

Penso que os participantes
ainda estarão disponíveis para questões

e para uma pausa.

- Divirtam-se.
- Muito obrigado.

(aplausos)