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)