Rule Mining with AMIE - Trabalho Relacionado Complementar

Sobre

Do Raphaël Troncy, meu colega no projeto europeu:

Thanks for this pointer! Interesting work! I skim through it and one of the related work I can think of but not cited is 1) the work of Fabian Suchanek with AMIE and rule mining in KG to detect automatically outliers / false values / inconsistent values / incongruences / etc. and 2) to some extent, the body of literature working on detecting pseudo-keys for doing entity matching, and again relying on mining property-values that are generally true for 90%+ of the entities but not for a few ones suggesting errors.
Did you look into this too?

Acho que vale dar uma olhada (me parece que seriam trabalhos complementares ao que a gente fez) para a tese.

[]s

Veronica: Do item 1, olhando as publicações do Fabian Suchanek no DBLP,  eu separei 3 artigos sobre o AMIE (2013, 2015, 2020) para ler. Dois são citados no survey da ACM sobre KG na seção 4.4.1 Rule Mining
Daniel: Lembrando que é um trabalho que poderia complementar o nosso, identificando restrições que deveriam existir, se n me engano.

Fiz a leitura comentada dos 3 artigos: 

Fast and Exact Rule Mining with AMIE 3 - Leitura de Artigo - Ano 2020
Fast rule mining in ontological knowledge bases with AMIE+ - Leitura de Artigo - Ano 2015
AMIE: Association Rule Mining under Incomplete Evidence in Ontological Knowledge Bases - Leitura de Artigo - Ano 2013

Segue um overview:

Mineração de Regras do tipo SE-ENTÃO permite:
1) Completar o KB/Database inferindo novas alegações (esta tarefa também é feita por Link Prediction via ML).
2) Debugar o KB/Database no sentido de encontrar potenciais erros.

A primeira geração de abordagens de mineração de regras (Inductive Logic Programming) usavam exemplos positivos e negativos como entrada pois operavam em CWA mas tinham problemas de escalabilidade no tamanho do KB/Database.

AMIE é da segunda geração uma vez que opera sob OWA e os algoritmos são otimizados para grandes volumes (KGs e não mais KB/Database) mas ainda apresentam desafios em termos de eficiência para calcular o suporte e confiança das regras. O suporte de uma regra R em um KB K é o número de previsões verdadeiras p (da forma r(X, Y )) que a regra faz no KB. A confiança de uma regra R em um KB K é a proporção de previsões verdadeiras em relação ao total das previsões verdadeiras e previsões falsas.

AMIE é voltado para KG somente com relações binárias, não consideram qualificadores e nem o modelo multi camadas. Já existem abordagens ML para Link Prediction que consideram os qualificadores (STAR-E). Não comentam qual seria o impacto da reificação nesta abordagem. Em trabalhos de ML já se admitiu que a reificação prejudica a geração do modelo.

A mineração de regras do AMIE não usa o esquema, somente instâncias. Mas o tipo de regras geradas poderiam ser úteis para completar a definição de constraints e esquemas ShEx da WD. AMIE gera regras do tipo SE-ENTÃO (Horn) fechadas e com átomos conectados.

No artigo de 2020 eles reportam ter usado WD dump de Julho de 2019 mas não explicam se foi o truthy. 

Nos experimentos também relataram que removem as triplas onde o objeto é um literal (focam em relações e não em propriedades) e isto também eu já li que é feito em algoritimos de Predição de Link. 

Para gerar contraexemplos para entrada no processo definiram o conceito de partial completeness assumption (PCA). Se existe <s1,p1,o1> no KB K então existe qualquer <s1,p1,*> (e estes não podem ser contra exemplos) mas se não existe qualquer <s2,p2,*> no KB K então <s2,p2,o2> é um contra exemplo. Na análise qualitativa sobre PCA eles alegam que a geração de contra exemplos adequados depende da natureza da relação, quando as mesmas são funções (ou exibem um comportamento semelhante) o PCA seria mais adequado.

Na WD existe a opção de criar uma alegação que represente uma negação, por exemplo, <Fulano child no_value>. Mas não exploramos isso (e nem eles, por estes artigos)

Também podemos na WD criar uma alegação onde o valor para uma determinada propriedade ou relação é desconhecido mas deveria existir, por exemplo, <Fulano bornIn unknow_value>. Este recurso poderia ser usado para atender a uma regra "Se <sujeito1 predicado1 objeto1> Então <sujeito1 predicado2 objeto2>" gerada criando uma alegação <sujeito1 predicado2 unknown_value>. Alternativamente este regra também poderia justificar a criação de uma constraint no predicado1 do tipo "item requires statement" para o predicado2. Não exploramos este tipo de constraint no nosso artigo.

Uma possível extensão para o AMIE seria explorar o modelo hiper relacional (ou multi camadas) e gerar regras que permitissem inferir/completar as constraints de required e allowed qualifiers com os qualificadores/contextos que se aplicam a uma relação (predicado). As métricas de suporte e confiança poderia ser usadas para decidir se mandatórias ou sugeridas e required ou allowed.