Dentre os 3 problemas de pesquisa identificados, um está localizado na modelagem dos dados das aplicações desenvolvidas pelo BioBD usando o modelo RDF: triplas não permitem representar nativamente relações com aridade maior que 2 assim como não suportam propriedades para as arestas.
Um outro problema foi especificar / restringir o contexto da Busca como no busc@nima … mas o que quer dizer CONTEXTO? Como o contexto está representado no KG? Será que o problema anterior e o contexto tem alguma relação?
Além disso, um questionamento recorrente é se o uso de palavras chaves e linguagem natural para acessar KG seria um problema do domínio de Information Retrieval ou Banco de Dados?
Sobre o RDF e modelos de dados em grafo temos:
RDF é um modelo de dados especificado pela W3C e, em sua essência, trata-se de uma coleção de triplas que permite a representação de um grafo direcionado, rotulado e multi-grafo (ou seja, um par de nós pode ter mais de uma aresta rotulada entre eles). Já o modelo LPG (grafo de propriedades rotuladas) permite modelar grafos direcionados, rotulados, multi-grafos e com propriedades do tipo chave/valor tanto nos nós quanto nas arestas. Mas não suportam IRI / URI (identificadores únicos do RDF) e nós brancos (que são usados na reificação do RDF).
A reificação permite reduzir relacionamentos n-ários a n relacionamentos binários e suportar atributos nas arestas através do uso de nós brancos tornando o RDF com o mesmo poder de expressividade do LPG. Os atributos nas arestas permitem a especificação de metadados sobre as triplas (meta-knowledge), como por exemplo dados de proveniência. A reificação também se aplica a LPG para representação de relações n-árias.
O último relatório do grupo de trabalho sobre RDF-star e SPARQL-star foi gerado em julho de 2021. Atualmente é suportado pelo Blazegraph (que não está sendo mais atualizado), AnzoGraph da Cambridge Semantics além de algumas ferramentas RDF* e como extensão das ferramentas de conversão do Apache Jena (RDF * ↔ RDF, SPARQL * → SPARQL)
Declarações do Wikidata (quins e não triplas ou quads)
Mas na Wikidata não são representadas diretamente relações com aridade maior que 2, ou seja, entre 3 ou mais QNodes.
Sobre o MAG
A Filiação do Autor em relação ao Paper escrito é uma exemplo de relação ternária nesse KG mas, até onde eu pude verificar, na geração do MAKG (Microsoft Academic Knowledge Graph) proposta em um artigo "Linked Data Source with 8 Billion Triples of Scholarly Data" da ISWC'19, nenhuma abordagem de reificação foi utilizada, perdendo parte da semântica da informação.
Anotações do Sérgio
- Sobre limites do RDF e sabermos justificar bem o porque desta nossa escolha. Por um lado dizem que é lento, por outro que é rápido e apropriado, ... segue valendo mesmo com restrições?
- Esta proliferação de triplas para representar coisas que no relacional seria mais simples deve ser bem pensada e comentada.
- A ideia é explorar quad stores mesmo ou seguem triple stores adaptadas?
- Definição formal de hiper-relacional
Sobre o posicionamento da abordagem de busca em KG
No SBBD 2020, o professor Altigran (UFAM), apresentou um tutorial sobre NLIDB. A busca por palavras-chaves em BDs pode ser baseados em Esquemas, em Instâncias ou em Caminhos. São mais próximas das abordagens de IR uma vez que a consulta não está vinculada a resposta exata. As abordagens de consulta em Linguagem Natural em BDs (NLIDB) pode ser de Sistemas Centrados em Dados e Sistemas Centrados em Linguagens.
ALTIGRAN: A ideia de keyword search é igual a busca do Google, simples e para gerar exploração posterior pelo usuário X Consulta por linguagem natural visa recuperar resultado exato usando linguagem natural para gerar consultas com linguagem específica do modelo.
Um exemplo de NLIDB é o DukeNLIDB escrito em Java e testado com PostgreSQL. DukeNLIDB, baseado no NaLIR. O NaLIR é o baseline dessas abordagens, publicado no VLDB 2014 (Best Paper). O grupo do Altigram converteu o NaLIR para python.
DukeNLIDB: no passo 1 gera a árvore T (árvore de dependência sintática NLP). O mapeamento dos nós da árvore com o grafo do esquema, no passo 2, usa funções de similaridade semântica, baseada na WordNet, e similaridade sintática, baseada no coeficiente de Jaccard. O mapeamento das palavras reservadas da sintaxe SQL é feito usando regras. O resultado dessa etapa é um conjunto de consultas candidatas com um rankeamento. O passo 3 de ajuste lida com as ambiguidades dos mapeamentos c om o feedback do usuário. No final (4) gera uma consulta SQL que retorna uma resposta exata.
Mais recente (2020) tem o ATHENA++ que usa Ontologias de domínio e Ontologias de mapeamento entre o Domínio e o Esquema de BD como exeplo de NLIDB.
As abordagens de keyword search over RDF realizam a correspondência de palavra-chave com rótulos de nós ou das arestas além dos valores das propriedades dos nós. Em RDF como arestas não tem outras propriedades, além do rótulo, não seria possível fazer diretamente o match com o contexto que o fato contido na tripla pode estar associado. Nessa etapa de correspondência meramente sintática é onde pode ocorrer o Semantic Mismatch, mesmo que seja uma função de match que use algum recurso externo para como a WordNet, um dicionário de sinônimos, etc ...
Com os nós e arestas mapeados no passo anterior em relação a lista de palavras chaves, o algoritmo precisa encontrar um subgrafo que corresponda a uma componente conexa mínima em termos de nós e arestas e máxima em termos de mapeamentos de palavras-chaves. Considerando abordagens baseadas em esquema, o algoritmo precisa considerar o tipo de reificação adotado no esquema para gerar a consulta SPARQL. Já as abordagens baseadas em instância devem considerar todos os tipos de reificação possíveis uma vez que o esquema não é conhecido (explorado).
Os subgrafos recuperados com as consultas podem ser ordenados de acordo com uma pontuação dos nós e arestas que o compõem usando usando métricas como PageRank, Saliency, InfoRank.
Anotações do Sérgio
- Slides 11: como fica o "quem@puc" ou o "busc@nima"?
- Slide 14: já coisa de RDF*?
Em relação a proposta de busca semântica em hyper grafos relacionais apresentada no WTDBD
Partindo do tipo de busca realizada pelas aplicações: pergunta específica para retornar uma lista de objetos que pertençam a um tipo de entidade do grafo
Who researches about subject X from Environment domain?
Which individuals of an entity type T are related to subject X from context C?
O primeiro problema é o Semantic Mismatch da consulta com o conteúdo (rótulos e valores de propriedades) no KG que descreve a entidade. Aqui se faz necessário definir a função de similaridade (usando Text embeddings + Graph embeddings). O contexto das palavras é identificado pelas palavras que ocorrem próximas no espaço (cão e gato são animais domésticos) permitindo um soft match ao invés de um exact match.
O segundo problema é especificar / restringir o Search Context como no busc@nima … mas o que quer dizer CONTEXTO nesse caso e como o contexto está representado no KG? Aqui o contexto é meta-informação (em dados eram os metadados) e pode ser temporal, geográfico, de proveniência (fonte) ou até mesmo de Domínio / Tema. Na Wikidata o contexto é modelado através de qualificadores sobre a informação factual, informação factual é verdadeira em um determinado contexto. Esse contexto é independente de consulta e deve ser parte da resposta a consulta.
Context of Knowledge (extracted from Knowledge Graphs @ ACM Computing Surveys)
“By context, we herein refer to the scope of truth, and thus talk about the context in which some data are held to be true”
Fonte: https://dl.acm.org/doi/pdf/10.1145/3447772
E o terceiro diz respeito a dificuldade de representar com RDF as propriedades das arestas e os relacionamento n-ários uma vez que não existe um padrão definido ainda, ou seja, Reificação.
Questionamento da banca: “pq não RDF já que é um padrão consolidado para representação de bases de conhecimento em grafos”
Eu: Pq a representação de relações n-árias e propriedades das triplas não é nativamente representado em RDF (expressividade) e não existe um padrão de representação. Em abordagens KwS RDF baseadas em esquema, é possível saber qual opção de reificação foi utilizada mas as consultas SPARQL são mais complexas, em abordagens KwS RDF baseadas em instâncias mais de uma opção de reificação pode estar presente no grafo. Os algoritmos para identificação do subgrafo conexo podem não identificar todas as triplas que compõem a informação factual uma vez que buscam um subgrafo minimal em relação as triplas envolvidas então a resposta pode ser incompleta.
Daniel: Outro ponto em relação ao rdf. No nosso caso, estamos interessados em usar o contexto, o q na prática requer usar propriedades das propriedades. Este é um problema conhecido em rdf, e todas as soluções propostas envolvem basicamente substituir cada tripla por 4 triplas, o q introduz complexidade tanto nas queries qto na implementação. Por isso estão considerando a proposta do RDF*, q tem ainda poucas implementações.
Questionamento da banca: “pq a busca em RDF seria sintática e não semântica”
Eu: Pq a etapa de mapaeamento das palavras-chaves em nós do KG é feita por exact match e não por soft match.
Daniel: Em relação à semantica, ela tb é incluida no CONTEXTO, e na possibilidade do usuário informar isto na query
Eu: Agora reli com mais atenção a essa perspectiva da importância do contexto para interpretação da veracidade do conhecimento representado no KG, independente da forma de representação. Nesse caso contexto são meta-informações temporal, geográfica, de proveniência (fonte), etc ... mas originalmente eu havia pensado em contexto como o tema / domínio que especifica a semântica das palavras chaves e restringe o espaço de busca do usuário como no caso do busc@nima ser Meio Ambiente.
Daniel: Pois é, são as duas coisas.
Anotações do Sérgio
- Contextos independentes das consultas -- modelar a base/repositório ("store") sem depender do que o usuário tá buscando.
- Noção de verdade, comprovação de fatos na BD - justificar respostas às consultas
Comentários
Postar um comentário
Sinta-se a vontade para comentar. Críticas construtivas são sempre bem vindas.