A Web Semântica e os Dados Ligados são como o espaço sideral: não há vida lá. Ir para lá por muito tempo... bem, eu não sei o que te disseram quando você era criança e dizia: "Quero ser astronauta". Mas você pode observar o que está acontecendo da Terra; tornar-se um astrônomo amador ou mesmo profissional é muito mais fácil.
Este artigo abordará as tendências recentes no mundo do armazenamento RDF, que surgiram há poucos meses. A metáfora no primeiro parágrafo foi inspirada pela imagem promocional de tamanho épico abaixo do corte.
Imagem épica
I. GraphQL para acesso RDF
que o GraphQL pretende se tornar uma linguagem universal de acesso a bancos de dados. E quanto à capacidade de acessar RDF usando GraphQL?
Fora da caixa, esta oportunidade é fornecida por:
- Stardog (, );
- Produtos TopQuadrant (, ).
Se o repositório não oferecer essa oportunidade, ele poderá ser implementado de forma independente, escrevendo um “resolvedor” apropriado. Foi o que fizeram, por exemplo, no projecto francês . Ou você não pode mais escrever nada, apenas pegue .
Do ponto de vista de um adepto ortodoxo da Web Semântica e do Linked Data, tudo isso, claro, é triste, pois parece projetado para integrações construídas em torno do próximo silo de dados, e não para plataformas adequadas (lojas RDF, é claro) .
As impressões da comparação do GraphQL com o SPARQL são duplas.
- Por um lado, GraphQL parece um parente distante do SPARQL: resolve os problemas de reamostragem e multiplicidade de consultas típicos do REST - sem os quais, provavelmente, não seria possível considerar Linguagem de consulta, pelo menos para a web;
- Por outro lado, o esquema rígido do GraphQL é decepcionante. Assim, a sua “introspectividade” parece muito limitada em comparação com a plena reflexividade do RDF. E não existe análogo de caminhos de propriedade, então nem está muito claro por que é “Graph-”.
II. Adaptadores para MongoDB
Uma tendência complementar à anterior.
- agora em Stardog - em particular, tudo no mesmo GraphQL - configure o mapeamento de dados MongoDB em gráficos RDF virtuais;
- GraphDB recentemente insira fragmentos no SPARQL na consulta MongoDB.
Se falarmos mais amplamente sobre adaptadores para fontes JSON, que permitem representar mais ou menos “on the fly” o JSON armazenado nessas fontes como RDF, podemos lembrar o já antigo , que pode ser ajustado, , para Apache Jena.
Resumindo as duas primeiras tendências, podemos dizer que os armazenamentos RDF demonstram total prontidão para integração e operação em condições de “persistência poliglota”. Sabe-se, porém, que este último está há muito fora de moda e está sendo substituído por multimodelo. E quanto à multimodelagem no mundo do armazenamento RDF?
Em suma, de jeito nenhum. Gostaria de dedicar um artigo separado ao tópico de SGBDs multimodelos, mas por enquanto pode-se notar que atualmente não existem SGBDs multimodelos “baseados” em um modelo gráfico (RDF pode ser considerado um tipo dele) . Algumas pequenas multimodelagens - suporte de armazenamento RDF para um modelo gráfico alternativo de GLP - serão discutidas em .
III. OLTP vs. OLAP
No entanto, o mesmo Gartner que o multimodelo é uma condição sine qua non principalmente para salas de cirurgia SGBD. Isto é compreensível: numa situação de “armazenamento multivariado”, os principais problemas surgem com a transacionalidade.
Mas onde estão localizados os armazenamentos RDF na escala OLTP-OLAP? Eu responderia assim: nem lá nem aqui. Para indicar a que se destinam, é necessária uma terceira abreviatura. Como opção eu sugeriria OLIP — Processamento Intelectual Online.
No entanto, ainda assim:
- os mecanismos de integração com MongoDB implementados em GraphDB não são menos importantes para contornar problemas de desempenho de gravação;
- Stardog vai ainda mais longe e completamente motor, novamente com o objetivo de melhorar o desempenho de gravação.
Agora, permita-me apresentar um novo participante no mercado. Dos criadores do IBM Netezza e do Amazon Redshift — . Uma foto de um anúncio de um produto baseado nele foi postada no início do artigo. O AnzoGraph se posiciona como uma solução GOLAP. O que você acha do SPARQL com funções de janela? -
SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }XNUMX. RochasDB
Já mais alto ao anúncio do Stardog 7 Beta, que dizia que o Stardog usaria o RocksDB como um sistema de armazenamento subjacente - um armazenamento de valor-chave, um fork do Facebook do LevelDB do Google. Por que vale a pena falar sobre uma determinada tendência?
Em primeiro lugar, a julgar por , não apenas os armazenamentos RDF são “transplantados” para RocksDB. Existem projetos para usar RocksDB como mecanismo de armazenamento em ArangoDB, MongoDB, MySQL e MariaDB, Cassandra.
Em segundo lugar, projetos (ou seja, não produtos) sobre temas relevantes são criados no RocksDB.
Por exemplo, o eBay usa RocksDB em para o seu “gráfico de conhecimento”. Aliás, é engraçado ler: a linguagem de consulta começou como um formato desenvolvido internamente, mas mais recentemente está em transição para se parecer muito mais com SPARQL. Como na piada: não importa quanto gráfico de conhecimento façamos, ainda assim acabamos com RDF.
Outro exemplo – que apareceu há alguns meses . Antes de sua introdução, as informações históricas do Wikidata tinham que ser acessadas através de para a API Mediawiki padrão. Agora muito é possível com SPARQL puro. “Sob o capô” também existe o RocksDB. A propósito, o WDHQS foi feito, ao que parece, pela pessoa que importou o Freebase para o Google Knowledge Graph.
V. Apoio ao GPL
Deixe-me lembrá-lo da principal diferença entre gráficos GLP e gráficos RDF.
No LPG, as propriedades escalares podem ser atribuídas a instâncias de aresta, enquanto no RDF elas só podem ser atribuídas a “tipos” de aresta (mas não apenas propriedades escalares, mas também conexões comuns). Esta limitação do RDF em comparação com o GLP uma ou outra técnica de modelagem. As limitações do GLP em comparação com o RDF são mais difíceis de superar, mas os gráficos do GLP são mais parecidos com imagens de um livro Harari do que com gráficos RDF, e é por isso que as pessoas os querem.
Obviamente, a tarefa de “apoio ao GPL” divide-se em duas partes:
- fazer alterações no modelo RDF que possibilitem nele simular estruturas de GLP;
- fazer alterações na linguagem de consulta RDF que tornem possível acessar dados neste modelo modificado ou implementar a capacidade de fazer consultas a este modelo em linguagens de consulta LPG populares.
V.1. Modelo de dados
Existem várias abordagens possíveis aqui.
V.1.1. Propriedade Singleton
A abordagem mais literal para harmonizar o CDR e o GPL é provavelmente :
- Em vez de, por exemplo, o predicado
:isMarriedTopredicados são usados:isMarriedTo1,:isMarriedTo2etc - Esses predicados tornam-se então sujeitos de novos trigêmeos:
:isMarriedTo1 :since "2013-09-13"^^xsd:dateetc - A conexão dessas instâncias de predicados com um predicado comum é estabelecida por trigêmeos da forma
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo. - Obviamente, o
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, mas pense por que você não deveria simplesmente escrever:isMarriedTo1 rdf:type :isMarriedTo.
O problema do “apoio ao GPL” é resolvido aqui ao nível do RDFS. Tal decisão requer inclusão no apropriado . Algumas alterações podem ser necessárias para armazenamentos RDF que suportam a anexação de consequências, mas por enquanto, a propriedade Singleton pode ser considerada apenas mais uma técnica de modelagem.
V.1.2. Reificação bem feita
Abordagens menos ingênuas decorrem da constatação de que as instâncias de propriedade são totalmente instanciáveis por trigêmeos. Ao podermos dizer algo sobre trigêmeos, seremos capazes de falar sobre instâncias de propriedade.
A mais robusta dessas abordagens é , também conhecido como RDR, nas profundezas do Blazegraph. É desde o início para você e para o AnzoGraph. A solidez da abordagem é determinada pelo facto de, no seu âmbito, alterações correspondentes em . A questão, porém, é extremamente simples. Na serialização Turtle do RDF agora você pode escrever algo assim:
<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .V.1.3. Outras abordagens
Você não pode se preocupar com a semântica formal, mas simplesmente assumir que os trigêmeos possuem determinados identificadores, que são, obviamente, URIs, e criar novos trigêmeos com esses URIs. Resta apenas dar acesso a esses URIs no SPARQL. Então Stardog.
Em Alegrógrafo de forma intermediária. Sabe-se que os identificadores de trigêmeos no Allegrograph , mas ao implementar atributos triplos eles não se destacam. No entanto, ainda está muito longe da semântica formal. Vale ressaltar que os atributos trigêmeos não são URIs, e os valores desses atributos também podem ser apenas literais. Os adeptos do GLP conseguem exatamente o que queriam. No formato NQX especialmente inventado, um exemplo semelhante ao acima para RDF* se parece com este:
:bob :marriedTo :alice {"since" : "2013-09-13"}V.2. Linguagens de consulta
Tendo suportado o GLP de uma forma ou de outra no nível do modelo, você precisa tornar possível fazer consultas nos dados desse modelo.
- Blazegraph para consultas RDF* suporta и . Uma consulta SPARQL* se parece com isto:
SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }- Anzograph também suporta e vai apoiar , uma linguagem de consulta no Neo4j.
- Stardog suporta o seu próprio SPARQL e Gremlin. Você pode obter o URI triplo e a “meta-informação” no SPARQL usando algo assim:
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}- Allegrograph também suporta seu próprio SPARQL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }A propósito, o GraphDB já suportou Tinkerpop/Gremlin sem oferecer suporte a GLP, mas isso parou na versão 8.0 ou 8.1.
VI. Reforço das licenças
Não houve adições recentes à interseção dos conjuntos "triplestore de escolha" e "triplestore de código aberto". Novos armazenamentos de dados RDF de código aberto estão longe de se tornarem uma opção viável para o uso diário, e o código-fonte dos novos armazenamentos de dados RDF que gostaríamos de usar (como o AnzoGraph) é fechado. É mais provável que tenha havido até mesmo algumas reduções...
É claro que o código aberto não foi encerrado no passado, mas alguns repositórios de código aberto aos poucos não são mais vistos como dignos de escolha. O Virtuoso, que tem uma edição opensource, está, na minha opinião, afogado em bugs. Blazegraph foi adquirido pela AWS e formou a base do Amazon Neptune; agora não está claro se haverá pelo menos mais um lançamento. Apenas Jena permanece...
Se o código aberto não é muito importante, mas você apenas quer experimentá-lo, então tudo também é menos otimista do que antes. Por exemplo:
- Stardog distribuir a versão gratuita (no entanto, o período de teste da versão regular dobrou);
- в , onde antes era possível escolher um plano básico gratuito, suspendeu o cadastro de novos usuários.
Em geral, para o profissional médio de TI, o espaço está se tornando cada vez mais inacessível; seu desenvolvimento está se tornando o destino das corporações.
Fonte: habr.com
