O que está acontecendo agora com os repositórios RDF?

A Web Semântico e os Dados Linked são semelhantes ao espaço próximo: não há vida lá. Para embarcar nessa jornada por um período mais ou menos longo... bem, não sei o que te disseram na infância em resposta a "quero ser astronauta". Mas você pode observar o que acontece mesmo estando na Terra; tornar-se um astrônomo amador ou até profissional é muito mais fácil.

Neste artigo, falaremos sobre as tendências recentes, com não mais de alguns meses, do mundo dos armazenamentos RDF. A metáfora no primeiro parágrafo foi inspirada por uma imagem de proporções épicas abaixo.

Imagem épica

I. GraphQL para acesso ao RDF

Dizem, que o GraphQL se propõe a ser a linguagem universal de acesso a bancos de dados. Mas como está a possibilidade de acesso utilizando GraphQL ao RDF?

«De fábrica», essa possibilidade é oferecida por:

• Stardog (blog, documentação);
• produtos da TopQuadrant (webinar, documentação).

Se o armazenamento não oferece essa possibilidade, ela pode ser implementada por conta própria, escrevendo um "resolvedor" correspondente. Foi assim que, por exemplo, no projeto francês DataTourisme. Ou agora já não é preciso escrever nada, basta pegar HyperGraphQL.

Do ponto de vista de um ortodoxo defensor do Web Semântico e dos Dados Linked, tudo isso, claro, é triste, pois parece destinado a integrações construídas em torno de novos silos de dados, e não adequadas para plataformas (evidentemente, armazenamentos RDF).

As impressões da comparação do GraphQL com o SPARQL são ambíguas.

• Por um lado, o GraphQL parece um parente distante do SPARQL: ele resolve problemas característicos de reconsulta e múltiplas consultas do REST — sem os quais, provavelmente, não poderia ser considerado uma linguagem de consulta, mesmo que seja para a web;
• Por outro lado, decepciona a rigidez do esquema do GraphQL. Consequentemente, sua "introspectividade" parece muito limitada em comparação com a plena reflexividade do RDF. E não há nenhum análogo a property paths, então nem está claro por que é "Graph-".

II. Adaptadores para MongoDB

Uma tendência complementar à anterior.

• Agora na Stardog talvez — em particular, tudo no mesmo GraphQL — configura-se a representação de dados do MongoDB em gráficos RDF virtuais;
• O GraphDB, recentemente, permite começou a inserir fragmentos do MongoDB Query no SPARQL.

Falando de maneira mais ampla, sobre adaptadores para fontes JSON, que permitem, mais ou menos "em tempo real", representar o JSON armazenado nessas fontes como RDF, podemos lembrar do já existente SPARQL Generate, que pode ser adaptado, por exemplo, para Apache Jena.

Resumindo as duas primeiras tendências, pode-se dizer que os repositórios RDF demonstram total prontidão para integrações e funcionamento em condições de "armazenamento poliglotas" (polyglot persistence). Sabe-se, no entanto, que isso já não está na moda, e está sendo substituído por multimodalidade. E como estão as coisas com a multimodalidade no mundo dos repositórios RDF?

Resumindo, não estão. O tema dos SGBDs multimodais merece um artigo dedicado, mas pode-se notar, por enquanto, que não existem SGBDs multimodais "baseados" em modelo gráfico (pode-se considerar uma variedade dele o RDF) atualmente. Sobre uma certa pequena multimodalidade — suporte dos repositórios RDF a um modelo gráfico alternativo LPG — será abordado na seção V.

III. OLTP vs. OLAP

No entanto, o mesmo Gartner escreve, que a multimodalidade é uma condição sine qua non, principalmente para SGBDs operacionais. É compreensível: na situação de "armazenamento poliglotas", os principais problemas surgem com a transacionalidade.

Mas onde na escala OLTP—OLAP estão os repositórios RDF? Eu responderia assim: nem lá, nem aqui. Para descrever a que se destinam, precisa ser utilizada alguma terceira abreviação. Como opção, eu sugeriria OLIP — Online Intellectual Processing.

No entanto, ainda assim:

• os mecanismos de integração realizados no GraphDB não são, em última análise, destinados a contornar problemas de desempenho de gravação;
• o Stardog vai ainda mais longe e reescreve completamente o motor, novamente com o objetivo de aumentar o desempenho de gravação. E agora, permita-me apresentar um novo jogador no mercado. dos criadores do IBM Netezza e Amazon Redshift —

AnzoGraph . A imagem do produto baseada nele foi publicada no início do artigo. O AnzoGraph se posiciona como uma solução GOLAP. O que você acha de SPARQL com funções de janela? —SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }

IV. RocksDB

Acima já

houve uma referência ao anúncio do Stardog 7 Beta, onde foi dito que o Stardog planeja usar RocksDB como sistema de armazenamento subjacente — um armazenamento "chave-valor", um fork do LevelDB do Google feito pelo Facebook. Por que já vale a pena falar sobre uma certa tendência? Em primeiro lugar, de acordo com

um artigo da Wikipédia , os repositórios RDF não são os únicos que estão "migrando" para o RocksDB. Existem projetos utilizando o RocksDB como motor de armazenamento em ArangoDB, MongoDB, MySQL e MariaDB, Cassandra.Em segundo lugar, estão sendo feitos projetos (ou seja, não produtos) sobre o tema correspondente no RocksDB.

Em segundo lugar, projetos relacionados são realizados no RocksDB (ou seja, não produtos).

Por exemplo, o eBay utiliza RocksDB na plataforma para seu 'grafo de conhecimento'. Aliás, é engraçado ler: a linguagem de consulta começou como um formato desenvolvido internamente, mas recentemente tem se transformado para ser muito mais parecido com SPARQL. Como na piada: não importa quantos grafos de conhecimento fazemos, sempre acabamos em RDF.

Outro exemplo — surgiu há alguns meses Wikidata History Query Service. Antes de sua criação, para informações históricas do Wikidata, era necessário recorrer ao MWAPI do padrão Mediawiki API. Agora, muito é possível com puro SPARQL. Aliás, parece que quem fez o WDHQS foi a pessoa que esteve envolvida na importação do Freebase para o Google Knowledge Graph.

V. Suporte a LPG

Lembro-me da principal diferença entre grafos LPG e grafos RDF.

Em LPG, podem ser anexadas propriedades escalares aos instantes de arestas, enquanto em RDF elas só podem ser anexadas a 'tipos' de arestas (mas não apenas propriedades escalares, mas também relações normais). Esta limitação do RDF em comparação com o LPG é superada por várias técnicas de modelagem. A limitação do LPG em comparação ao RDF é mais difícil de superar, mas os grafos LPG são mais parecidos com as imagens do livro de Harari, por isso as pessoas os desejam.

Obviamente, a tarefa de 'suporte a LPG' se divide em duas partes:

1. fazer alterações no modelo RDF para possibilitar a simulação de estruturas LPG;
2. fazer alterações na linguagem de consultas RDF para permitir acessar dados nesse modelo modificado, — ou implementar a possibilidade de fazer consultas a esse modelo em linguagens de consulta populares para LPG.

V.1. Modelo de dados

Aqui existem várias abordagens possíveis.

V.1.1. Propriedade Singleton

A abordagem mais literal para harmonizar RDF e LPG é, provavelmente, a singleton property:

• Em vez, por exemplo, do predicado :isMarriedTo utilizam-se os predicados :isMarriedTo1, :isMarriedTo2 etc.
• Depois, esses predicados tornam-se sujeitos de novos triplos: :isMarriedTo1 :since "2013-09-13"^^xsd:date etc.
• A relação dessas instâncias de predicados com o predicado comum é estabelecida por triplos do tipo :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
• É evidente que rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, mas pense por que não devemos simplesmente escrever :isMarriedTo1 rdf:type :isMarriedTo.

A tarefa de 'suporte a LPG' é resolvida aqui no nível RDFS. Essa solução requer modificações na especificação. Algumas alterações podem ser necessárias por parte dos repositórios RDF que suportam a anexação de consequências, enquanto isso, a Propriedade Singleton pode ser vista simplesmente como mais uma técnica de modelagem.

V.1.2. Reificação Feita da Maneira Certa

Abordagens menos ingênuas derivam da compreensão de que instâncias de propriedades podem ser perfeitamente instanciadas em tripletos. Sendo capaz de falar algo sobre tripletos, teremos a capacidade de falar sobre instâncias de propriedades.

A abordagem mais sólida entre elas é RDF*, também conhecido como RDR, nascido nas entranhas do Blazegraph. Desde o início, ele foi escolhido para si mesmo e para o AnzoGraph. A solidez da abordagem é definida pelo fato de que, dentro de sua estrutura, são oferecidos mudanças correspondentes em Semântica RDF. A essência, no entanto, é extremamente simples. Na serialização Turtle do RDF, agora podemos escrever algo assim:

<> :since "2013-09-13"^^xsd:date.

V.1.3. Outras Abordagens

É possível não se preocupar com a semântica formal e simplesmente considerar que os tripletos têm certos identificadores, que são, naturalmente, URIs, e compor novos tripletos com esses URIs. Resta apenas fornecer acesso a esses URIs no SPARQL. Assim, faz Stardog.

No Allegrograph, seguiram um caminho intermediário. É conhecido que os identificadores de tripletos no Allegrograph tem, mas ao implementar atributos tripletos para fora, eles não são expostos. No entanto, ainda está muito longe da semântica formal. Notavelmente, os atributos de tripletos não são URIs, e os valores desses atributos também podem ser somente literais. Os adeptos do LPG obtêm exatamente o que queriam. Em um formato especialmente inventado NQX, um exemplo semelhante ao mencionado acima para RDF* se parece com isso:

:bob :marriedTo :alice {"since" : "2013-09-13"}

V.2. Linguagens de Consulta

Apoiando, de uma forma ou de outra, o LPG no nível do modelo, é necessário permitir que consultas sejam feitas aos dados nesse modelo.

• O Blazegraph para consultas ao RDF* suporta SPARQL* e Gremlin.Uma consulta em SPARQL* se parece com isso:

 SELECT * { <> :since ?since }

• AnzoGraph também suporta SPARQL* e planeja suportar Cypher, a linguagem de consulta em Neo4j.
• O Stardog suporta seu próprio extensão SPARQL e novamente Gremlin. O URI do tripleta e a "metainformação" podem ser obtidos em SPARQL com uma construção semelhante a esta:

SELECT * { BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id) ?id :since ?since }

• Allegrograph também suporta seu próprio extensão SPARQL:

 SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }

A propósito, o GraphDB, por um tempo, suportou Tinkerpop/Gremlin, sem suportar LPG, mas na versão 8.0 ou 8.1 isso foi interrompido.

VI. Endurecimento das Licenças

Não houve adições recentes nas interseções entre "triplestore de escolha" e "triplestore de código aberto". Os novos repositórios RDF de código aberto ainda estão longe de se tornarem uma boa escolha para uso cotidiano, e o código fonte de novos repositórios RDF que gostaríamos de explorar (como o AnzoGraph) está fechado. Podemos até falar de reduções...

Claro, o código-fonte aberto não está sendo fechado, mas alguns repositórios de código aberto estão lentamente deixando de ser considerados escolhas dignas. O Virtuoso, que tem uma edição opensource, na minha opinião, está afundando em bugs. O Blazegraph foi adquirido pela AWS e se tornou a base do Amazon Neptune; agora não está claro se haverá mais lançamentos. Resta apenas o Jena...

Caso o código-fonte aberto não seja tão importante e você queira apenas experimentar, a situação também não é tão otimista quanto antes. Por exemplo:

• Stardog deixa de distribuir a versão gratuita (no entanto, o período de teste padrão dobrou);
• em GraphDB Cloud, onde anteriormente era possível escolher um plano básico gratuito, suspendeu o registro de novos usuários.

No geral, para o cidadão comum de TI, o espaço se torna cada vez mais inacessível, e seu domínio se torna privilégio das corporações.

Fonte: habr.com