cdn.media.ccc.de/.../wikidatacon2019-9-eng-Data_quality_panel_hd.mp4

Olá a todos,
ao painel de Qualidade de Dados.

A qualidade dos dados é importante porque
cada vez mais pessoas

dependem do bom estado dos nossos dados.

Assim, vamos falar da qualidade dos dados.

Haverão quatro oradores que farão
breves introduções acerca de tópicos

relacionados com qualidade de dados.
Depois, responderemos a perguntas.

O primeiro é o Lucas.

Obrigado.

Olá. O meu nome é Lucas e vou começar
com uma síntese

das ferramentas de qualidade de dados
que já existem na Wikidata

e também de algumas coisas
que teremos em breve.

Agrupei-as em temas gerais

que são a maior visibilidade dos erros,
tornar os problemas accionáveis,

obter mais visibilidade sobre os dados
para que mais pessoas notem os problemas,

corrigir algumas fontes comuns de erros,
manter a qualidade dos dados existentes

e também a curadoria humana.

As que estão atualmente disponíveis
começam com as restrições de propriedades.

Já o devem ter visto se usam a Wikidata.

Podem, por vezes, obter estes ícones

que verificam
a consistência interna dos dados.

Por exemplo,
se um evento se seguir a outro,

então a este último deve seguir-se este.

O que estava aparentemente em falta
no item WikidataCon.

Não tenho a certeza, esta funcionalidade
existe há apenas uns dias.

Também existe... Se isto for
demasiado simples ou condicionante,

podem escrever quaisquer verificações
que queiram usando o Query Service

que é útil para várias coisas,

mas também pode ser usado
para encontrar erros.

Por exemplo, se descobrirem
uma ocorrência de um erro,

podem verificar se existem outros locais

onde as pessoas tenham feito
um erro parecido

e descobri-lo com o Query Service.

Também podem combinar os dois e procurar
violações de restrições no Query Service,

como por exemplo,
apenas violações que ocorram numa área

ou WikiProject que seja
relevantes para vocês.

Embora, atualmente, os resultados
não estejam completos. Infelizmente.

Existe a avaliação de revisões.

Penso que seja parte
das alterações recentes.

Podem também adicioná-la à vossa lista
de visualização: uma avaliação automática

da probabilidade desta edição
ter sido feita em boa ou má-fé

e da probabilidade de causar ou não danos.

Penso que sejam essas as duas dimensões.

Podem, se quiserem,

concentrar a busca apenas
nas edições danosas mas feitas com boa-fé.

Se se estiverem a sentir particularmente
amigáveis e acolhedores

podem dizer a estes editores:
"Obrigado pela contribuição.

Deviam tê-la feito desta maneira,
mas obrigado de qualquer forma."

E, se não estiverem com essa disposição,

podem rever as edições
danosas feitas com má-fé

e reverter o vandalismo.

Existe também algo semelhante:
avaliação de entidades.

Em vez de classificar uma edição,
a alteração que foi feita,

vão classificar toda a revisão.

Penso que seja a mesma medida de qualidade

mencionada pela Lydia
no início da conferência.

Isto fornece um script de utilizador aqui
em cima e uma pontuação de um a cinco,

penso eu, da qualidade do item corrente.

A ferramenta de fontes primárias é para
bases de dados que queiram importar,

mas que não têm qualidade suficiente
para entrar diretamente na Wikidata.

Ao invés, adicionam-nas à ferramenta
de fontes primárias e, depois,

as pessoas podem decidir

se devem adicionar
estas declarações individuais ou não.

Mostrar coordenadas como mapas:
é uma funcionalidade conveniente

mas também é útil
para controlo de qualidade.

Por exemplo, se virem que isto devia ser
o escritório da Wikimedia na Alemanha

e as coordenadas forem algures
no Oceano Índico,

saberão que algo está errado, aqui.

E podem vê-lo mais facilmente
do que se tivessem apenas os números.

Esta é uma engenhoca chamada
indicador de integridade relativa,

que apresenta este pequeno ícone

que vos mostra o quão completo
pensa que este item está

e que propriedades
é mais provável que estejam em falta.

O que é muito útil
se estiverem a editar um item,

estiverem numa área com a qual
não estejam muito familiarizados

e não saibam quais são
as propriedades certas a usar.

Nesse caso, esta é
uma miniaplicação muito útil.

Temos o Shape Expressions.

Penso que a Andra ou o Jose
vão falar mais sobre elas

mas são uma forma muito poderosa
de comparar os dados que têm

com o esquema.

Como, que declaração devem ter
certas entidades,

a que outras entidades devem estar ligadas
e como essas devem ser.

Podem detetar problemas dessa forma.

Penso que... Não. Ainda há mais.

O Integraality ou painel de propriedades.

Dá-vos uma visão geral
dos dados já existentes.

Por exemplo, isto é do
WikiProject Red Pandas.

Podem ver que temos
um sexo ou género

para quase todos os pandas-vermelhos.

A data de nascimento varia bastante
consoante o zoo de onde vêm

e quase não temos
pandas mortos, o que é maravilhoso

(risos)

porque são tão fofos.

Por isso, isto também é útil.

Cá está. Agora para o que está para vir.

Wikidata Bridge, anteriormente conhecida
como editor de clientes.

Ou seja, editar dados a partir
de caixas de informação da Wikipedia.

O que, por um lado, dará
mais visibilidade aos dados

pois mais pessoas os conseguirão ver ali.

E, assim se espera, encorajará uma maior
utilização da Wikidata nas Wikipedias.

Isto significa
que mais pessoas podem reparar

se, por exemplo, há dados desatualizados
que precisam de ser atualizados,

ao invés de só os verem
na própria Wikidata.

Existem também as referências corrompidas.

Aqui, a ideia é que, se editarem
uma declaração de valor,

pode ser preciso atualizar também
as referências,

a não ser
que seja apenas uma gralha, ou similar.

Estas referências corrompidas
dizem-no aos editores

e também que os outros editores
vêm as outras edições que foram feitas

que editaram uma declaração de valor
e não atualizaram a referência.

Depois, podem limpar
e decidir se isso deve...

Precisam de fazê-lo novamente

ou está tudo correto e
não é necessário atualizar a referência.

Tem relação com declarações assinadas.
Que têm origem numa preocupação, penso eu,

que alguns fornecedores de dados têm de...

Há uma declaração que é referenciada
através na UNESCO, ou similar.

Depois, de repente,
alguém vandaliza a declaração

e eles estão preocupados que parecerá que

essa organização, como a UNESCO,
ainda define este valor de vandalismo.

Assim, com declarações assinadas,

eles podem assinar
essa referência criptograficamente.

Isso não vai prevenir edições à referência

mas, se alguém vandalizar a declaração

ou se a editar de alguma forma
a assinatura deixa de ser válida.

E pode-se ver que isto não é exatamente
o que foi dito pela organização.

Pode ser que seja uma boa edição
e eles devam assinar a nova declaração,

mas também pode acontecer
que deva ser revertida.

E também... Isto vai ser
muito empolgante, penso eu.

O Citoid é um sistema fantástico
que existe na Wikipedia

no qual podem colar um URL,
um identificador, um ISBN,

um ID da Wikidata ou
outra coisa qualquer no Visual Editor,

e ele devolve uma referência
bem formatada.

Tem todos os dados que quiserem
e uma usabilidade excelente.

Por comparação, na Wikidata,
se eu quiser adicionar uma referência,

tenho, tipicamente, de adicionar o URL,
título, nome de autor,

data de publicação da referência,

recuperar as datas.
No mínimo, o que é aborrecido.

Espera-se que a integração do Citoid
na Wikibase ajude com isso.

Penso que é tudo o que tinha. Sim.

Vou agora passar à Cristina.

(aplausos)

Olá, eu sou a Cristina.

Sou uma cientista de investigação
da Universidade de Zurique

e também um membro ativo
da comunidade Suíça.

Quando eu e a Claudia Müller-Birn
submetemos isto à WikidataCon,

o que queríamos era continuar a discussão
que começámos no início do ano

numa workshop acerca de qualidade de dados
e também nalgumas sessões na Wikimania.

Então, o objetivo desta palestra
é apresentar algumas ideias

que estivemos a compilar,
nossas e da comunidade,

e continuar a discussão.

Gostaríamos de continuar
a interagir muito convosco.

O que pensamos ser muito importante,

é perguntarmos continuamente a todos
os tipos de utilizador na comunidade,

o que realmente precisam,
que problemas têm com qualidade de dados.

Não apenas os editores, mas também
as pessoas que estão a programar

ou a consumir os dados.

E também os investigadores que estão
a usar toda a história de edições

para analisar o que está a acontecer.

Assim, fizemos uma avaliação de cerca
de 80 ferramentas que existem na Wikidata

e alinhámo-las com as diferentes
dimensões de qualidade de dados.

O que vimos foi que, na realidade,

muitas delas estão a vigiar,
a monitorizar a integridade,

mas, na verdade... Algumas delas estão
também a capacitar interligações.

Mas, existe uma grande necessidade
de ferramentas que vejam a diversidade,

que é uma das coisas
que podemos ter na Wikidata.

Especialmente, este princípio
do design da Wikidata,

segundo o qual podemos ter pluralidade

e declarações diferentes
com valores diferentes

originárias de fontes diferentes.

Visto ser uma fonte secundária,
não temos realmente ferramentas

que nos digam
quantas declarações plurais existem,

quantas podemos melhorar e como.

Também não sabemos

quais são todas as razões
para pluralidade que podemos ter.

Assim, a partir destes
encontros da comunidade

o que discutimos foram os desafios
que ainda necessitam de atenção.

Por exemplo, que ter
todas estas comunidades de crowdsourcing

é muito bom, já que pessoas diferentes
atacam partes diferentes dos dados

ou do gráfico.

Temos também conhecimentos
de origem diferentes.

Mas, na realidade, é muito difícil alinhar
tudo em algo que seja homogéneo

pois pessoas diferentes usam propriedades
diferentes de forma diferente.

E estão também à espera de coisas
diferentes das descrições de entidade.

Foi também dito
que são necessárias mais ferramentas

que dêm uma melhor visão geral
do estado global das coisas.

Ou seja, que entidades estão em falta,
em termos de integridade,

mas também no que é que as pessoas
estão a trabalhar hoje em dia,

na maior parte do tempo.

Também foi mencionada com frequência
uma colaboração mais apertada

entre, não só as linguagens,
mas os WikiProjects

a as diferentes plataformas Wikimedia.

Publicámos todos
os comentários transcritos

de todas estas discussões
nestas ligações aqui, no Etherpads

e também na página wiki da Wikimania.

Algumas das soluções que apareceram

vão na direção da partilha
das melhores práticas

que estão a ser desenvolvidas
nos diferentes WikiProjects.

Mas, as pessoas também querem ferramentas

que ajudem a organizar
o trabalho em equipa

ou, pelo menos, a perceber
quem está a trabalhar em quê.

Também foi mencionada
a vontade de ter mais demonstrações

e mais modelos que os ajudem
a criar coisas de uma forma melhor.

E, pelo contacto que temos

com organizações
de dados governamentais abertas

e, em particular,

eu estou em contacto com o cantão
e a cidade de Zurique,

eles estão muito interessados
em trabalhar com a Wikidata

porque querem que os seus dados
estejam acessíveis para todos

no local onde as pessoas vão
e consultam ou acedem aos dados.

Assim, para eles, algo que
seria mesmo interessante

seria ter algum tipo
de indicador de qualidade

tanto na wiki,
o que já acontece atualmente,

como nos resultados SPARQL.

Para saber se podem ou não confiar
dos dados da comunidade.

Eles também querem saber que partes
dos seus próprios conjuntos de dados

são úteis para a Wikidata.

E adorariam ter uma ferramenta
que ajudasse a avaliar automaticamente.

Também precisam
de algum tipo de metodologia ou ferramenta

que os ajude a decidir se devem
ou não importar ou ligar os seus dados

pois, nalguns casos,eles também têm

os seus próprios conjuntos de dados
abertos ligados e não sabem

se devem apenas incorporar os dados
ou continuar a criar ligações

dos conjuntos de dados
à Wikidata e vice-versa.

Também querem saber se os seus websites
forem referidos na Wikidata.

E, quando correm essas consultas
no serviço de consultas

recebem, muitas vezes, timeouts.

Por isso, talvez devêssemos mesmo
criar mais ferramentas

que os ajudem a obter estas respostas
para as suas questões.

(ruído de fundo)

E, para além disso,

nós, investigadores da wiki, também

temos falta de alguma informação
nos sumários de edição.

Lembro-me que, quando
estávamos a trabalhar

para compreender os diferentes
comportamentos dos editores

com ferramentas ou bots,
ou utilizadores anónimos, etc,

faltava-nos realmente, por exemplo,

uma forma padrão de registar
que as ferramentas estavam a ser usadas.

Já existem algumas ferramentas
que fazem isso

como o PetScan e muitas outras

mas talvez devêssemos, na comunidade,

debater mais acerca de como
registar estes eventos

para obter uma origem otimizada.

E, no futuro,

precisamos de pensar em dimensões
de qualidade de dados mais concretas

que estão relacionadas com dados ligados
mas não com todos os tipos de dados.

Por isso, trabalhámos nalgumas medidas
para aceder ao aumento de informação

proporcionado pelas ligações.
O que queremos dizer com isso

é que, quando ligamos a Wikidata
a outros conjuntos de dados,

também deviamos estar a pensar

em quanto é que as entidades estão,
na realidade, a ganhar na classificação,

na descrição, mas também
nos vocabulários que usam.

Para dar um exemplo muito simples
do que quero dizer com isto,

podemos pensar... Neste caso,
seria a Wikidata

ou o centro de dados externo
que está a ligar à Wikidata.

Temos a entidade para uma pessoa
chamada Natasha Noy,

temos a afiliação e outras coisas.

E, depois dizemos: "Está bem, ligamos
a um local externo

e aquela entidade também tem aquele nome."
Mas, na realidade, temos o mesmo valor.

Então, seria melhor se ligássemos
a algo que tenha um nome diferente,

o que ainda é válido porque esta pessoa
tem duas formas de escrever o nome,

e também outras informações
que não temos na Wikidata

ou que não temos
no outro conjunto de dados.

Mas também, o que é ainda melhor

é que estamos a olhar
para o conjunto de dados alvo

e eles também têm novas formas
de classificar a informação.

Por isso, não só é uma pessoa,
mas, no outro conjunto de dados,

também diz que é do sexo feminino

ou qualquer outra classificação
que tenha sido usada.

Se, no outro conjunto de dados, estiverem
a usar muitos outros vocabulários

isso também está a ajudar
na recuperação de informação como um todo.

Também gostava de dizer

que pensamos que podemos
mostrar melhor as consultas federadas

porque, quando olhamos para o log
da consulta fornecido por Malyshev et al,

vemos que, das consultas orgânicas,
temos apenas algumas consultas federadas.

E, na realidade, a federação é uma
das vantagens chave de ter dados ligados.

Por isso, talvez a comunidade
ou as pessoas que usam a Wikidata

também precisem
de mais exemplos deste tipo.

Se olharmos para a lista
de parâmetros que estão a ser usados...

Esta não é uma lista completa
e temos muitos mais.

Estes dados foram analisados a partir
de consultas feitas até março de 2018,

mas deviamos olhar para a lista
de parâmetros federados que temos

e ver se os estamos realmente
a usar ou não.

Por isso, duas questões
que tenho para a audiência

e que talvez possamos usar
depois para a discussão, são:

que problemas de qualidade de dados
devem, na vossa opinião, ser abordados,

devido às vossas necessidades.

Mas também, onde é que é necessária
mais automação

para vos ajudar com as edições
ou patrulhamentos.

É tudo, muito obrigada.

(aplausos)

(Jose Emilio Labra) Vou falar-vos
de algumas ferramentas

que estamos a desenvolver,
relacionadas com o Shape Expressions.

É disto que quero falar...
Sou o Jose Emilio Labra,

mas há... Todas estas ferramentas
foram construídas por pessoas diferentes,

muitas relacionadas com o W3C ShEx,
Shape Expressions Community Group.

ShEx Community Group.

A primeira ferramenta que quero mencionar
é o RDFShape. Esta é uma ferramenta geral

porque o Shape Expressions
não é só para a Wikidata.

O Shape Expressions é uma linguagem
para validar RDF em geral.

Esta ferramenta foi desenvolvida
principalmente por mim

e é uma ferramenta para validar
RDF no geral.

Se quiserem aprender acerca de RDF
ou se quiserem validar parâmetros RDF

ou SPARQL, não só na Wikidata,

o meu conselho é
que podem usar esta ferramenta.

Também para ensinar.

Sou um professor universitário

e uso-a no meu curso de web semântica
para ensinar RDF.

Por isso, se quiserem aprender RDF,
penso que esta é uma boa ferramenta.

Por exemplo, esta é só uma visualização
de um gráfico RDF com essa ferramenta.

Mas, antes de vir cá, no último mês,

comecei um fork de rdfshape
especificamente para a Wikidata,

porque pensei...

Chama-se WikiShape e, ontem,
apresentei-a como presente à Wikidata.

Então, eu peguei...

O que eu fiz foi remover tudo
o que não tivesse relação com a Wikidata

e acrescentar várias coisas,
com codificação permanentemente,

como, por exemplo,
o parâmetro Wikidata SPARQL.

Agora, foi-me pedido
que fizesse isso também para a Wikibase.

E é muito fácil
fazê-lo também para a Wikibase.

Então, esta ferramenta,
a WikiShape, é muito recente.

Penso que funciona,
a maioria das funcionalidades,

mas há algumas funcionalidades
que podem não funcionar.

Se experimentarem e quiserem
melhorá-la, digam-me, por favor.

Isto é uma captura de ecrã,
mas penso que posso experimentar.

Por isso, vamos experimentar.

(risos)

Vamos ver se funciona.

Primeiro, tenho de sair do...

Aqui.

Esta é a ferramenta, aqui.

Coisas que podem fazer com a ferramenta:

por exemplo, podem
verificar esquemas, esquemas de entidades.

Sabem que há um novo namespace
que é "E" qualquer coisa".

Então, se começaram, por exemplo,
a escrever "humano",

à medida que escrevem,
o autocompletamento permite-vos verificar

que isto é o Shape Expressions
de um humano

e que isto é o Shape Expressions, aqui.

Como podem ver, este editor
tem realce de sintaxe.

Isto é... Bem, talvez seja
muito pequeno, o ecrã.

Posso tentar aumentá-lo.

Talvez o vejam melhor, agora.

Então, este é o editor, com realce
de sintaxe, e também tem...

Quero dizer, este editor
vem do mesmo código fonte

do editor de consultas da Wikidata.

Se pairarem com o rato aqui,

vai mostrar-vos as etiquetas
das diferentes propriedades.

Penso que é muito útil porque, agora,

o esquema de entidades
que está na Wikidata

é só uma ideia em texto simples.

Penso que este editor é muito melhor
porque tem autocompletamento

também tem...

Por exemplo, se quiserem adicionar
uma restrição

vão dizer: "wdt:".

Começam a escrever "author"
e depois clicam em Ctrl+Espaço

e vai sugerir-vos várias coisas.

Então, isto é semelhante
ao serviço de consultas da Wikidata,

mas para Shape Expressions,
especificamente.

Porque penso que, criar Shape Expressions

não é mais difícil do que
escrever consultas SPARQL.

Algumas pessoas pensam
que o nível de dificuldade é o mesmo.

É provavelmente mais fácil
porque o Shape Expressions era...

Quando o concebemos, fizemo-lo
para que fosse mais fácil trabalhar.

Esta é uma das primeiras coisas que têm.
Este editor para Shape Expressions.

Depois, também têm a possibilidade de,
por exemplo, visualizar.

Se tiverem uma Shape Expression,
usem, por exemplo...

Penso que "trabalho escrito" é
uma boa Shape Expression

porque tem algumas relações
entre diferentes coisas.

E isto é a visualização UML
do trabalho escrito.

Numa UML, isto é fácil de ver,
as diferentes propriedades.

Quando fazem isto, apercebi-me que,
quando o tentei com várias pessoas,

encontram alguns erros
nas suas Shape Expressions

porque é fácil detetar quais são
as propriedades em falta.

Depois, temos aqui outra possibilidade
que é a de poder também validar.

Penso que a temos aqui, a validação.

Pensava que a tinha nalguma etiqueta.
Talvez a tenha fechado.

Mas podem, por exemplo,
clicar aqui: Validar entidades.

Vocês, por exemplo,

"q42" com "e42", que é o autor.

Com "humano". Penso que o podemos fazer
com "humano".

E depois é...

Está a demorar um pouco a fazê-lo
porque está a realizar consultas SPARQL.

E agora, por exemplo, está a falhar
por causa da rede. Mas...

Podem tentá-lo.

Vamos continuar com a apresentação,
com outras ferramentas.

O meu conselho é, se o quiserem tentar
e se quiserem qualquer feedback, digam-me.

Então, para continuar
com a apresentação...

Isto é a WikiShape.

Já o disse,

o editor de Shape Expressions
é um projeto independente no GitHub.

Podem usá-lo no vosso próprio projeto.

Se quiserem construir
uma ferramenta de Shape Expressions,

podem integrá-lo
em qualquer outro projeto.

Está no GitHub e podem usá-lo.

O mesmo autor,
é um dos meus estudantes.

Ele também criou um editor
para Shape Expressions,

também inspirado pelo
serviço de consultas do Wikidata,

onde, numa coluna,

têm este editor mais visual
de consultas SPARQL

onde podem introduzir este tipo de coisas.

Esta é uma captura de ecrã.

Podem ver que isto
é Shape Expressions em texto,

mas isto é Shape Expressions
baseado em formas

onde, provavelmente,
demoraria um pouco mais,

onde podem pôr as diferentes colunas
nos diferentes campos.

Depois há o ShExEr.

Temos...Foi feito por um estudante
de doutoramento da Universidade de Oviedo.

E ele está cá,
por isso pode apresentar o ShExEr.

(Danny) Olá, eu sou o Danny Fernàndez.

Sou um estudante de doutoramento
na Universidade de Oviedo

a trabalhar com o Labra.

Já que estamos a ficar sem tempo,
vamos fazer isto rapidamente.

Não faremos uma demonstração,
mas veremos algumas capturas de ecrã.

A forma usual de trabalhar com
Shape Expressions,

ou com qualquer linguagem de formas,
é ter um perito no domínio

que define, a priori,
como se deve parecer o gráfico,

define algumas estruturas.

Depois usam essas estruturas
para comparar os dados e validá-los.

Esta ferramenta, que é, tal como aquelas
que o Labra esteve a apresentar,

uma ferramenta polivalente
para qualquer fonte RDF,

está concebida para fazer o contrário.

Já têm alguns dados,

selecionam que nodos
querem usar para formar a forma

e depois extraem ou inferem
a forma automaticamente.

Então, mesmo sendo
uma ferramenta polivalente,

o que fizemos para este WikidataCon
foi este botão catita.

Se clicarem nele,
o que acontece, essencialmente,

é que, há
tantos parâmetros de configuração,

e ele configura-os para funcionar
com os parâmetros da Wikidata.

Vai acabar em breve, desculpem.

Assim que pressionam este botão
o que obtêm é essencialmente isto.

Depois de selecionarem que tipo de nodos,

que tipo de instâncias da nossa classe,
ou seja o que for que estejam a procurar,

obtêm um esquema automático.

Todas as restrições são resolvidas
por quantos nodos são conformantes.

Podem filtrar os menos comuns, etc.

Há um poster lá em baixo
acerca disto.

Eu estarei lá em baixo e cá em cima,
em todo o lado o dia todo.

Por isso, se tiverem interesse adicional
nesta ferramenta

falem comigo durante esta jornada.

Vou devolver o microfone ao Labra.
Obrigado.

(aplausos)

(Jose) Vamos continuar com
as outras ferramentas.

A outra ferramenta é o ShapeDesigner.

Andra, queres falar
do ShapeDesigner agora

ou mais tarde, durante a workshop?

Há uma workshop...

Esta tarde, há uma workshop,
especifica para Shape Expressions, e...

A ideia é que vai ser mais
na vertente prática

e, se quiserem praticar ShEx,
podem fazê-lo lá.

Esta ferramenta é o ShEx,js.
Lá está o Eric, ali.

Podes apresentá-la.

(Eric) Muito rapidamente,
aquilo que quero dizer

é que já viram, provavelmente,
a interface de ShEx

que foi concebida para a Wikidata.

Ela foi simplificada e pensada
especificamente para a Wikidata

porque a versão genérica
tem mais funcionalidades.

Mas pensei em mencioná-la
porque uma dessas funcionalidades

é particularmente útil
para depurar esquemas da Wikidata.

A qual é, se selecionarem o modo slurp,

o que faz é dizer,
à medida que estou a validar,

que quero puxar
todos os triplos para baixo.

E, isso significa
que, se tiver um conjunto de falhas,

posso verificá-las e começar a olhar
para essas falhas e dizer

quais são os triplos que estão aqui.

Peço desculpas, os triplos estão
aqui em baixo.

Isto é só um registo do que aconteceu.

Depois, podem limitar-se a remexer
nisto em tempo real.

Brincam com alguma coisa e muda.

Então, é uma versão mais rápida
para fazer todas essas coisas.

Este é um formulário ShExC.

É algo que o Joachim sugeriu.

Pode ser útil para povoar
documentos da Wikidata

baseado numa Shape Expression
para esse documento.

Isto não foi feito
à medida da Wikidata,

mas é apenas para mostrar
que podem ter um esquema

e podem ter algumas anotações
para especificar

como quero apresentar o esquema.

Depois, constrói um formulário

e, se tiverem dados,
pode até povoar o formulário.

PyShEx [inaudível].

(risos)

(Jose) Penso que este seja o último.

Sim, o último é o PyShEx.

O PyShEx é uma implementação
de Shape Expressions em Python.

Podem também experimentar
o Jupyter Notebooks

se quiserem esse tipo de coisas.
É tudo, para isto.

(aplausos)

(Andra) Vou falar acerca
de um projeto específico

com o qual estou envolvido
chamado Gene Wiki

e onde também estamos a lidar
com questões de qualidade.

Mas, antes de falar da qualidade,

talvez uma pequena apresentação
acerca do que é o Gene Wiki.

Acabámos de lançar uma pré-impressão
de um artigo que escrevemos recentemente

que explica os detalhes do projeto.

Tiraram fotografias.

Basicamente, o que o Gene Wiki faz

é tentar inserir dados biomédicos,
dados públicos, na Wikidata.

Seguimos um padrão específico
para inserir esses dados na Wikidata.

Assim, quando temos um novo repositório,
ou um novo conjunto de dados

que é elegível
para ser incluído na Wikidata,

o primeiro passo
é o envolvimento da comunidade.

Não é dirigido, necessariamente
a uma comunidade da Wikidata,

mas a uma comunidade de pesquisa local.

Encontramo-nos em pessoa,
ou online, ou em qualquer plataforma

e tentamos criar um modelo de dados

que faça a ponte entre os seus dados
e o modelo Wikidata.

Aqui, tenho uma imagem de uma workshop
que aconteceu aqui, no ano passado.

Estava a tentar olhar
para um conjunto de dados específico

e, enfim, vêm muitas discussões,

e depois alinhá-los com o schema.org
e outras ontologias que por aí andam.

Depois, no final do primeiro passo,
temos um desenho do esquema

que queremos implementar na Wikidata.

O que vêm aqui, isto é apenas simples,

temo-lo lá atrás, ali,

e podemos fazer alguns esquemas
dentro deste painel mesmo hoje.

Assim que temos o esquema montado,

o próximo passo é tentar fazer
o esquema da máquina legível.

Porque querem ter modelos acionáveis
para fazer uma ponte

com os dados que estão a inserir
de qualquer base de dados biomédica

no Wikidata.

Aqui, estamos a aplicar Shape Expressions.

Usámo-lo porque permite-vos testar

se o conjunto de dados é, na realidade...
Não. A ver, em primeiro lugar,

se os dados que já existem na Wikidata
seguem o mesmo modelo de dados

que foi conseguido no processo anterior.

Depois, com a Shape Expression
podemos verificar:

os dados deste tópico na Wikidata,
será que precisam de uma limpeza

ou precisamos de adaptar o nosso modelo
ao modelo da Wikidata, ou vice-versa?

Quando isso estiver definido
e começarmos a programar bots

e os bots estão a passar a informação

que está nas fontes primárias
para a Wikidata.

Quando os bots estão prontos...

Programamos estes bots
com uma plataforma chamada...

com uma biblioteca de Python
chamada Wikidata Integrator

que foi criada pelo nosso projeto.

Uma vez que tenhamos os nossos bots,
usamos uma plataforma chamada Jenkins

para integração contínua.

Com o Jenkins,

atualizamos constantemente
as fontes primárias com a Wikidata.

Este é um diagrama para o artigo
que mencionei anteriormente.

Esta é a nossa paisagem atual.

Cada caixa laranja
é um recurso primário para drogas,

proteínas, genes, doenças
compostos químicos com interação.

Este modelo é muito pequeno
para ser lido agora,

mas esta é a base de dados,
as fontes, que gerimos na Wikidata

e que fazem ponte com as fontes primárias.

Aqui está um desses fluxos de trablaho.

Um dos nossos parceiros
é a Disease Ontology.

A Disease Ontology é uma ontologia CC0

e a ontologia CC0
tem o seu próprio ciclo de curadoria.

Eles atualizam continuamente
a Disease Ontology

para refletir o espaço de doenças
ou a interpretação de doenças.

Há também o ciclo de curadoria
da Wikidata acerca de doenças

onde a comunidade Wikidata
monitoriza constantemente

o que se está a passar na Wikidata.

Depois, temos duas funções

às quais chamamos, coloquialmente,
curadores guardiões.

Isto sou eu
e um colega há cinco anos atrás.

Ficamos ao computador
e monitorizamos a Wikipedia e a Wikidata

e, se houver alguma questão
reportada à comunidade primária,

aos recursos primários, eles olhavam
para a implementação e decidiam:

"Confiamos nas entradas da Wikidata?"

Se sim, é considerada,
entra no ciclo

e na próxima iteração
faz parte da Disease Ontology

e é fornecida à Wikidata.

Estamos a fazer o mesmo
com a WikiPathways.

A WikiPathways é um percurso
inspirado na wiki

e um repositório de percursos.

É a mesma história, já há diferentes
recursos de percursos na Wikidata.

Podem haver conflitos entre
esses recursos de percursos

e esses conflitos são comunicados de volta

pelos curadores guardiões
a essa comunidade

mantendo-se os ciclos
individuais de curadoria.

Mas, se se lembrarem do ciclo anterior,

mencionei aqui
apenas dois ciclos, dois recursos.

Temos de fazer isto
para cada recurso individual que temos

e temos de gerir o que se passa
porque, quando falo em curadoria,

quero dizer ir
às páginas de topo da Wikipedia,

às páginas de topo da Wikidata,
e tentar fazer isso.

Isso é muito para os dois curadores
guardiões que tínhamos.

Por isso,
quando estive numa conferência em 2016,

onde o Eric fez uma apresentação
sobre Shape Expressions,

aderi à onda e disse: "Está bem.

o Shape Expressions pode ajudar-nos
a detetar as diferenças na Wikidata

e isso permite que os guardiões tenham

relatórios mais eficientes
para comunicar."

Então, este ano, fiquei deliciado
com a entidade de esquemas

porque, agora, podemos guardar
esses esquemas de entidades na Wikidata,

mesmo na Wikidata,
enquanto, antes, estavam no GitHub,

e isto está em sintonia
com a interface da Wikidata.

Então, têm coisas
como discussões de documentos

mas também têm revisões.

Assim, podem impulsionar as páginas
de topo e as revisões na Wikidata

para usar isso para debater
acerca do que está na Wikidata

e o que está nos recursos primários.

Isto, que o Eric acabou de apresentar,
já é um grande benefício.

Aqui, fizemos uma Shape Expression
para o gene humano

e, depois, passámos-la através
de uma ShEx simples e, como podem ver,

já temos no...

Existe uma questão
que precisa de ser monitorizada,

onde há um item
que não encaixa naquele esquema

e, depois, podem já criar relatórios
de curadoria de entidades de esquemas

baseados em... e enviar isto para
os diferentes relatórios de curadoria.

Mas, o ShEx.js é uma interface construída

e, se puder mostrar cá atrás,
faço apenas dez,

mas temos dezenas de milhares
e, por isso, não é escalável.

Agora, o Wikidata Integrator
também suporta ShEx

e podemos repetir iterações de itens

onde dizemos "sim, não", "sim, não"
"verdadeiro, falso", "verdadeiro, falso".

Então,

aumentar um pouco a eficiência
ao lidar com os relatórios.

Mas, agora, isso dificulta
o Wikidata Query Service

e, recentemente, tivemos estrangulamentos.

Por isso, novamente, não é escalável.

É ainda um processo em curso,
o como lidar com modelos na Wikidata.

E, ShEx é, não só intimidante,

como a escala é demasiado grande
para lidarmos com ela.

Então, eu comecei a trabalhar. Esta é
a minha primeira validação do conceito,

ou exercício,
onde usei uma ferramenta chamada yED.

Comecei a desenhar aquelas Shape
Expressions e, porque...

E depois, regenerei este esquema

no seu formato adjacente
de Shape Expressions.

Isto iria abrir-se à audiência

que está intimidada
pelas linguagens Shape Expressions.

Mas, há um problema
com essas descrições visuais

porque isto também é um esquema
que foi desenhado em yEd por alguém.

E aqui está outro,
que é belíssimo.

Adorava ter isto na minha parede,
mas continua a não ser interoperável.

Quero acabar a minha palestra com...

É a primeira vez que...
Tenho roubado e usado este slide.

É uma honra tê-lo na audiência.

Gosto realmente disto:

"As pessoas acham que RDF é chato
porque é complicado.

A verdade á ainda pior. É tão simples

porque temos de trabalhar
com problemas do mundo real

que são horrivelmente complicados.

Embora possam evitar o RDF,

é mais difícil evitar dados complicados
e problemas computacionais complicados."

Isto é acerca de RDF, mas penso
que também pode ser aplicado à modelação.

Então, o meu argumento é,
devemos realmente...

Como é que avançamos com a modelação?

Devemos discutir ShEx
ou modelos visuais, ou...

Como é que continuamos?

Muito obrigado pelo vosso tempo.

(aplausos)

(Lydia) Muito obrigada.

Venham para a frente

para podermos abrir
as questões da audiência.

Existem questões?

Sim.

E, penso...
Para a câmara, precisamos de...

(Lydia a rir) Sim.

(Interveniente 1) Uma questão para a
Cristina, penso eu.

Mencionou, exatamente,
o termo "ganho de informação"

devido à ligação com outros sistemas.

Existe uma medida teórica de informação

que usa estatística e probabilidade
e se chama ganho de informação.

Tem o mesmo...

Quero dizer, estava a falar
exatamente dessa medida,

do ganho de informação
da teoria de probabilidade,

da teoria de informação,
ou apenas a usar esta entidade conceptual

para medir o ganho de informação
de alguma forma?

(Cristina) Não.
Nós definimos e implementamos medidas

que estão a usar a entropia de Shannon,
por isso, é isso que significa.

Não queria entrar em detalhes
acerca das fórmulas concretas...

(Interveniente 1) Não, claro.
Daí a pergunta.

- (Cristina) Mas sim...
- (Interveniente 1) Obrigado.

(Interveniente 2) Faço um
comentário, mais que uma questão.

(Lydia) Força.

(Interveniente 2) Tem havido
muito ênfase ao nível do item,

acerca de qualidade e integridade.

Uma das coisas que me preocupa é

não estarmos a aplicar o mesmo
às hierarquias e penso que temos a questão

das nossas hierarquias
não serem boas, com frequência.

Estamos a ver
que isto vai ser um problema real

com a pesquisa de Commons e outras coisas.

Uma das coisas que conseguimos fazer
é importar externa...

Da forma como os thesaurus externos
estruturam as suas hierarquias,

usando o qualificador
de conceitos mais geral P4900.

Mas, o que penso que seria realmente útil,
seriam melhores ferramentas para o fazer

para que possamos importar uma
hierarquia de thesaurus externa,

mapeá-la nos nossos itens da Wikidata.

Uma vez implementada
com esses qualificadores P4900,

podemos fazer ótimas
consultas através de SPARQL

para ver onde é que a nossa hierarquia
diverge dessa hierarquia externa.

Por exemplo, como podem saber,
Paula Morma, o utilizador PKM

faz muito trabalho em moda.

Por isso, usamos isso para puxar

a hierarquia
do Thesaurus Europeana Fashion

e a hierarquia do thesauros de moda
Getty AAT.

Depois, vemos onde as lacunas
estavam nos nossos itens de alto nível,

que são um problema real para nós
porque, com frequência,

estas são coisas que só existem
como páginas de desambiguação na Wikipedia

e, por isso,
temos muitos itens de alto nível

a faltar nas nossas hierarquias.

Isto é algo que precisamos de abordar
em termos de qualidade e de integridade.

O que realmente ajudaria

seriam melhores ferramentas
que a selva de scripts que escrevi.

Se alguém pudesse pôr isso
num bloco de notas PAWS em Python,

ser capaz de receber um thesaurus
externo, pegar na sua hierarquia,

a qual pode muito bem estar disponível
como dados ligados, ou pode não estar,

para depois transferi-lo para
declarações rápidas

para pôr em valores P4900.

E, mais tarde,

quando a nossa representação
ficar mais completa, atualizar os P4900s.

Porque, à medida que a nossa representação
fica ultrapassada, fica mais densa.

Os valores desses qualificadores
precisam de mudar

para representar que temos mais
da sua hierarquia no nosso sistema.

Se alguém pudesse fazer isso,
penso que seria muito útil.

Também precisamos
de olhar para outras estratégias

para aumentar a qualidade
e a integridade ao nível da hierarquia,

não só ao nível do item.

(Andra) Posso acrescentar algo?

Sim. E, na realidade, fazemos isso.

Posso recomendar olhar
para a Shape Expression que o Finn fez

com os dados léxicos
onde ele cria Shape Expressions

e depois desenvolve
sobre outras Shape Expressions.

Têm este conceito
de Shape Expressions ligadas na Wikidata

e, especificamente, o caso de uso,
se entendi bem,

é exatamente o que estamos a fazer
na Gene Wiki.

Têm a Disease Ontology
que é posta na Wikidata

e, depois, dados de doenças entram
e aplicamos Shape Expressions

para ver se encaixam com este thesaurus.

Existem outros thesaurus, ou outras
ontologias, para vocabulários controlados

que ainda precisam
de ser inseridos na Wikidata.

E é exatamente por isso que
o Shape Expressions é tão interessante.

Porque podemos ter uma Shape Expression
para a Disease Ontology,

uma Shape Expression para o MeSH.

Pode dizer: "Agora
quero verificar a qualidade."

Porque também tem,
na Wikidata, o contexto

de quando tem um vocabulário controlado.

Diz que a qualidade
está de acordo com isto

mas pode ter uma
comunidade discordante.

Por isso, as ferramentas
já estão implementadas,

mas, agora, precisamos
de criar esses modelos

e aplicá-los
aos diferentes casos de uso.

(Interveniente 2)
Uma Shape Expression é muito útil

logo que tenha a ontologia externa
mapeada na Wikidata.

Mas, o meu problema é que
está a chegar aquele ponto.

Que é perceber quanto da ontologia externa
não está ainda na Wikidata

e onde estão as lacunas.

É aí que penso que
ter ferramentas mais robustas

para ver o que está em falta
de ontologias externas

seria muito útil.

(Andra) O maior problema aqui

é, não tanto as ferramentas,
mas mais o licenciamento.

Pôr as ontologias na Wikidata
é, na realidade, muito fácil.

Mas, a maioria das ontologias têm,
como é que o posso dizer educadamente,

licenciamento restritivo e, por isso,
não são compatíveis com a Wikidata.

(Interveniente 2) Existe um enorme número
de thesaurus do setor público

em setores culturais.

- (Andra) Então precisamos de falar.
- (Interveniente 2) Sem problema.

(Andra) Então, precisamos de falar.

(Interveniente 3) O comentário
que quero fazer

é uma resposta para o James.

O que acontece é que
hierarquias fazem gráficos

e quando queremos...

Quero falar acerca de um
problema comum em hierarquias,

que são hierarquias circulares.

Elas voltam umas às outras
quando há um problema.

Não devíamos ter isso com hierarquias.

É engraçado que isto
acontece muito em categorias na Wikipedia.

Temos muitos círculos em categorias.

Mas, a boa notícia é que...

Tecnicamente, é um problema completo PMP,
por isso não o conseguimos encontrar,

e facilmente, se construirmos
um gráfico a partir disso,

mas há muitas formas
que foram desenvolvidas

para encontrar problemas
nestes gráficos de hierarquia.

Existe um artigo
chamado Finding Cycles...

Breaking Cycles in Noisy Hierachies.

Tem sido usado para ajudar
na classificação da Wikipedia inglesa.

Podemos pegar nisto
e aplicar estas hierarquias na Wikidata

e, depois, podemos encontrar
coisas que são problemáticas

e remover as que estão
a causar problemas.

E encontrar os problemas, na realidade.

Isto é só uma ideia, para que...

(Interveniente 2) Está tudo muito bem,
mas acho que está a subestimar

o número de más relações de subclasse
que nós temos.

É como ter uma cidade
que está completamente no país errado.

Existem ferramentas para geografia,
para identificar isso.

Precisamos de ter
muito melhores ferramentas em hierarquias

para identificar onde o equivalente
do item para o país

esteja a faltar completamente
ou se foi subclassificado

como algo que não signifique
algo completamente diferente.

(Lydia) Sim, penso
que está a chegar a algo

que eu e a minha equipa ouvimos sempre
de pessoas que reutilizam os nossos dados.

Com frequência, também.

Dados pontuais podem ser ótimos,

mas, se temos de olhar
para a ontologia, etc,

torna-se muito...

Penso que um dos grandes problems
que causa isto

é que muita da edição na Wikidata

acontece baseada
num item individual, não é?

Fazemos uma edição nesse item

sem nos darmos conta que isto
pode ter consequências globais

no resto do gráfico, por exemplo.

E, se as pessoas têm ideias
sobre como tornar isto mais visível,

as consequências de uma
edição local individual,

penso que seria útil explorá-lo.

Para melhor mostrar às pessoas
as consequências das suas edições,

que elas podem estar a fazer de boa fé,

quais são elas.

(Risos) Muito bem. Vamos começar consigo,
depois você, depois você e depois você.

(Interveniente 3) Bem, depois do debate,

só para exprimir a minha concordância
com o que o James estava a dizer.

Essencialmente, parece
que a coisa mais perigosa é a hierarquia.

Não a hierarquia, mas, de forma geral,

a semântica das relações de subclasse
vistas na Wikidata, certo?

Estive a estudar linguagens recentemente,
apenas para esta conferência

e, por exemplo, encontram-se muitos casos

onde a linguagem é parte de
e uma subclasse da mesma coisa.

Podemos dizer que temos
uma ontologia flexível.

A Wikidata dá-nos a liberdade
de exprimir isso, por vezes.

Porque, por exemplo

essa ontologia de linguagens
é também politicamente complicada, certo?

É bom estar numa posição que nos permita
expressar um nível de incerteza.

Mas imaginem alguém a querer
fazer leitura ótica a partir disso.

É mesmo problemático.

E, depois,

não penso que a ontologia
seja algo que foi importada de algures,

é algo que é originalmente nosso.

Diria que foi colhida da Wikipedia
mesmo no início.

Por isso pergunto-me... Esta
coisa do Shape Expressions é ótima,

e também validadora e reparadora.
A ontologia da Wikidata

a partir de recursos externos
é uma bela ideia.

No final,

acabaremos por refletir
as ontologias externas na Wikidata?

E também, o que fazemos
com a parte central da nossa ontologia

que nunca é colhida
a partir de recursos externos.

Como é que solucionamos isso?

Penso, realmente, que isso
será um problema por si só.

Teremos de nos focar nisso
independentemente da ideia

de validar a ontologia com algo externo.

(Lydia aponta para a audiência)

(Interveniente 4) Restrições e formas
são muito impressionantes,

aquilo que podemos fazer com elas,

mas o ponto principal
não está claro.

Porque agora podemos tornar mais explícito
o que esperamos dos dados.

Antes, cada um tinha de escrever
as suas próprias ferramentas e scripts.

Por isso, é mais visível
e podemos discuti-lo.

Mas porque não é sobre
o que está errado ou certo,

é acerca de uma expectativa.

Vocês terão
diferentes expectativas e debates

acerca de como queremos
modelar as coisas na Wikidata

e isto...

O estado atual é apenas
um passo na direção

porque agora precisamos

de muito conhecimento especializado
para lidarmos com isto.

Precisamos de formas melhores
de visualizar esta restrição,

para a transformar,
porventura em linguagem natural,

para que as pessoas
melhor a possam entender.

Mas não é tanto
acerca do errado ou do certo.

(Lydia) Sim.

(Interveniente 5) Para questões
de qualidade, só quero fazer eco...

Definitivamente, encontrei muitos
dos problemas. Encontrei...

diferenças de opinião
entre "instâncias de" versus "subclasse".

Diria, erros, nestas situações.

E tentar encontrá-los
tem sido um processo moroso.

O que encontrei foi:
"Se eu encontrar itens de grande impressão

que são algo...

e depois usar
todas as instâncias das subclasses

para encontrar
todas as declarações derivadas disto."

Esta é uma forma muito útil
de olhar para estes erros.

Mas eu estava curioso para saber
se o Shape Expressions...

se há...

Se isto pode ser usado como ferramenta
para ajudar a resolver estas questões.

Mas sim...

(Interveniente 6) Se tem
uma pegada estrutural...

Se tem uma pegada estrutural
que podemos... que seja falsificável.

Podemos olhar para isso
e dizer: "Está errado."

Então sim, podemos fazer isso.

Mas se for só tentar mapeá-lo
para objetos do mundo real

então vai precisar
de muitos cérebros.

(Interveniente 7) Olá. Pablo Mendes
do Siri Knowledge da Apple.

Estamos aqui para descobrir como ajudar
o projeto e a comunidade,

mas a Cristina cometeu o erro
de perguntar o que queríamos.

(risos) Por isso, penso
que uma das coisas que gostaria de ver

gira à volta da verificabilidade,

que é um dos princípios chave
do projeto na comunidade.

E confiabilidade.

Nem todas as declarações são iguais,
algumas são fortemente disputadas,

outras são fáceis de adivinhar.

A data de nascimento de alguém
pode ser verificada,

como viram hoje na Keynote,
questões de género são mais complicadas.

Podem discutir um pouco do que sabem

nesta área de qualidade de dados, acerca
de confiabilidade e de verificabilidade?

(risos)

Se não há muito,
gostaria de ver muito mais. (risos)

(Lydia) Sim.

Aparentemente, não temos muito a dizer
acerca disso. (risos)

(Andra) Penso que podemos fazer muito,
mas tive uma discussão consigo ontem.

O meu exemplo preferido que, soube ontem,
foi descontinuado,

é, se forem ao Q2, que é Terra,

existe uma declaração
que reivindica que a Terra é plana.

Adoro esse exemplo

porque há uma comunidade
por aí que afirma isso

e eles têm recursos verificáveis.

Por isso, penso que seja um caso genuíno.

Não deve ser descontinuado,
deve estar na Wikidata.

E penso que o Shape Expressions
pode ser fundamental aqui,

porque podem dizer:

"Sim, estou mesmo interessado
neste caso de uso",

ou que este é um caso de uso
com o qual não concordam.

Mas também pode haver um caso de uso
onde dizem: "Estou interessado."

Há este exemplo. Dizem:
"Tenho glucose."

E a glucose, se forem um biólogo,

As restrições químicas
da molécula de glucose não vos interessam,

apenas... tudo o que seja
glucose é o mesmo.

Mas, se forem um químico,
arrepiam-se ao ouvir isso.

Têm 200 e tal...

Depois, podem ter
Shape Expressions múltiplas.

Vou entrar com...
Estou no ponto de vista de um químico,

vou aplicar isso.

E depois, dizem,
"sou um caso de uso de um biólogo",

e aplicam essa Shape Expression.

E, quando quiserem colaborar,

deviam falar com o Eric acerca
dos mapas ShEx.

Esta jornada está apenas a começar.

Mas acredito que seja muito
instrumental nessa área.

(Lydia) Ali.

(risos)

(Interveniente 8) Tive várias ideias
para alguns pontos na discussão,

por isso, vou tentar não perder...
Tive três ideias, por isso...

Baseado no que o James disse há pouco,

temos um grande problema
na Wikidata desde o início

para a ontologia superior.

Falámos acerca disso
há dois anos na WikidataCon

e falámos acerca disso na Wikimania.

Sempre que temos um encontro da Wikidata

estamos a falar sobre isso.

Porque é um grande problema
que está muito visível:

que entidade é, com que trabalho é,
que género é, arte,

são realmente o maior conceito.

E isso é um ponto muito fraco
na ontologia global

porque as pessoas
tentam fazer limpezas regularmente

e quebram tudo o que está a montante.

Penso que alguns de vocês
se devem lembrar do tipo que, em boa-fé,

quebrou todas as cidades do mundo.

Já não eram itens geográficos. Por isso,
violações de restrições por todo o lado.

E foi feito em boa fé,

porque ele estava a corrigir
um erro num item,

mas quebrou tudo.

Não tenho a certeza de como
podemos resolver isso

porque não há, atualmente, nenhuma
instituição externa que possamos copiar

porque toda a gente está a trabalhar em...

Se eu for base de dados
de artes performativas

limito-me a ir
à etiqueta de artes performativas

ou não irei ao conceito filosófico
do que é aquela entidade

e isso é, na realidade...

Não conheço nenhuma base de dados
que esteja a trabalhar a este nível,

mas esse é o ponto mais fraco da Wikidata.

E, provavelmente, quando falamos
de qualidade de dados,

isso é uma grande parte, por isso...

Penso que é o mesmo
que afirmamos em...

Desculpem, estou a mudar de assunto,

mas afirmámos, em diferentes sessões
acerca de qualidade,

que alguns de nós estão a fazer
um bom trabalho de modelação,

estamos a fazer ShEx,
estamos a fazer coisas como essa.

As pessoas não o veem na Wikidata,
não veem o ShEx,

não veem o WikiProject
na página de discussão

e, por vezes,
nem veem a página de topo das propriedades

que diz, explicitamente:
a) Esta propriedade é usada para isto.

Como na semana passada.
Eu adicionei restrições a uma propriedade.

A restrição estava escrita explicitamente
na discussão da criação da propriedade.

Eu criei apenas a parte técnica
de adicionar a restrição, e alguém:

"O quê? Quebraste
todas as minhas edições!"

Ele esteve a usar a propriedade
erradamente nos útlimos dois anos.

A propriedade era bastante clara,
mas não havia avisos.

É o mesmo no Pink Pony.

Dissemos, na Wikimedia que deviamos
tornar o WikiProject mais visível

ou tornar o ShEx mais visível, mas...

E isso foi o que a Cristina disse.

Temos um problema de visibilidade,
do que são as soluções.

E, nesta sessão,

estamos todos a falar acerca
de como criar mais ShEx,

ou de facilitar o trabalho
das pessoas que estão a fazer a limpeza.

Mas, estamos a limpar
desde o primeiro dia da Wikidata

e, globalmente, estamos a perder.

Estamos a perder porque,
se eu sei que os nomes são complicados,

mas eu sou a única a fazer
o trabalho de limpeza...

A pessoa que adicionou
nome de script em Latim

a todos os investigadores chineses.

Vou demorar meses a limpar isso
e não o posso fazer sozinha.

E ele fez um lote maciço.

Por isso, precisamos realmente...

Temos um problema de visibilidade
mais do que um problema de ferramentas,

porque temos muitas ferramentas.

(Lydia) Bem, infelizmente
mostraram-me um sinal. (risos)

Por isso, precisamos de terminar.

Muito obrigada pelos vossos comentários.

Espero que continuem a debater
durante o resto do dia.

Obrigada pelo vosso contributo.

(aplausos)