A Web Semântica e os Dados Vinculados são semelhantes ao espaço próximo: a vida não existe. Para ir lá por um período mais ou menos longo ... bem, não sei o que eles disseram na infância em resposta a "Quero me tornar um astronauta". Mas você pode observar o que está acontecendo e estar na Terra; Tornar-se astrônomo amador ou mesmo profissional é muito mais fácil.
O artigo se concentrará em novas tendências, não anteriores a alguns meses, do mundo dos repositórios RDF. A metáfora no primeiro parágrafo foi inspirada nesta imagem publicitária de tamanho épico.
Conteúdo
I. GraphQL para acessar RDF
II Adaptadores para MongoDB
III OLTP vs. OLAP
IV RocksDB
V. Suporte a GPL
V.1 Modelos de dados
V.1.1 Propriedade Singleton
V.1.2 Reificação feita corretamente
V.1.3 Outras abordagens
V.2 Idiomas de consulta
VI Licenças mais restritas
I. GraphQL para acessar RDF
Eles dizem que o GraphQL afirma ser uma linguagem universal para acessar bancos de dados. E a capacidade de usar o GraphQL para acessar o RDF?
Fora da caixa, esta oportunidade é fornecida por:
Se o repositório não fornecer essa oportunidade, ele será implementado independentemente, escrevendo o resolvedor correspondente. Isso foi feito, por exemplo, no projeto francês DataTourisme . Ou você já não pode escrever nada, apenas use o HyperGraphQL .
Do ponto de vista do seguidor ortodoxo da Web Semântica e dos Dados Vinculados, tudo isso, é claro, é triste, porque parece destinado a integrações que são construídas em torno de silos de dados regulares e não é adequado para essa plataforma (é claro, armazenamento RDF).
As impressões da comparação do GraphQL com o SPARQL são duas.
- Por um lado, o GraphQL parece um parente distante do SPARQL: resolveu os problemas específicos de REST de buscar novamente e multiplicar as consultas - sem as quais, provavelmente, seria impossível ser considerado uma linguagem de consulta, mesmo para a web, e ter "-QL" no nome;
- Por outro lado, os circuitos rígidos do GraphQL perturbam. Consequentemente, sua "introspecção" parece muito limitada em comparação com a reflexividade total da RDF. E como não há caminhos análogos para propriedades, não está muito claro por que é "Gráfico".
II Adaptadores para MongoDB
Uma tendência complementar à anterior.
- No Stardog, agora é possível - em particular, tudo no mesmo GraphQL - configurar o mapeamento dos dados do MongoDB em gráficos RDF virtuais;
- O Ontotext GraphDB recentemente permite inserir fragmentos no SPARQL no MongoDB Query.
Falando de maneira mais ampla, sobre adaptadores para fontes JSON que permitem mais ou menos "on the fly" representar JSON como RDF, vale lembrar o SPARQL Generate , que existe há bastante tempo, que pode ser anexado, por exemplo , ao Apache Jena.
Resumindo as duas primeiras tendências, pode-se dizer que os armazenamentos RDF demonstram sua total disponibilidade para integrações e funcionamento sob as condições de “armazenamento multivariado” (persistência poliglota). Sabe-se, no entanto, que este último está fora de moda e o multimodelo está vindo para substituí-lo. E o multimodelo no mundo do armazenamento RDF?
Em suma, de jeito nenhum. Gostaria de dedicar um artigo separado ao tópico do DBMS multimodal. Enquanto isso, você pode ver que não há DBMSs multimodelos nos quais o modelo principal seria um gráfico (vários deles podem ser considerados RDF). Alguns pequenos modelos múltiplos - suporte ao repositório RDF para um modelo gráfico alternativo de GPL - serão discutidos na Seção V.
III OLTP vs. OLAP
No entanto, o mesmo Gartner escreve que o multimodeling é uma condição sine qua non principalmente para DBMSs operacionais . É compreensível: em uma situação de “armazenamento multivariado”, os principais problemas surgem com a transacionalidade.
Mas onde estão os repositórios RDF na escala OLTP - OLAP? Eu responderia assim: nem lá nem aqui. Para indicar a que se destinam, é necessária alguma terceira abreviação. Como alternativa, eu sugeriria o OLIP - Online Intellectual Processing.
No entanto, ainda:
- Os mecanismos de integração do GraphDB implementados com o MongoDB não são menos projetados para contornar problemas de desempenho de gravação;
- O Stardog vai ainda mais longe e reescreve completamente o mecanismo, novamente com o objetivo de melhorar o desempenho da gravação.
Agora, deixe-me apresentar um novo player ao mercado. Dos criadores do IBM Netezza e Amazon Redshift - AnzoGraph . A imagem do anúncio do produto com base nele foi colocada no início do artigo. O AnzoGraph se posiciona como uma solução GOLAP. Como você gosta do SPARQL com funções de janela? -
SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }
IV RocksDB
Acima, já havia um link para o anúncio do Stardog 7 Beta, que dizia que o Stardog usaria o RocksDB como o sistema de armazenamento subjacente - armazenamento de valor-chave, fork do Facebook no LevelDB do Google. Por que vale a pena falar sobre uma certa tendência?
Primeiro, a julgar pelo artigo da Wikipedia , não apenas os repositórios RDF são transferidos para o RocksDB. Existem projetos sobre o uso do RocksDB como um mecanismo de armazenamento no ArangoDB, MongoDB, MySQL e MariaDB, Cassandra.
Em segundo lugar, projetos (isto é, não produtos) do assunto correspondente estão sendo feitos no RocksDB.
Por exemplo, o eBay usa o RocksDB na plataforma para o seu "gráfico de conhecimento". A propósito, é divertido ler: a linguagem de consulta começou como um formato desenvolvido em casa, mas, mais recentemente, passou a ser muito mais parecida com SPARQL . Como na piada: não importa quanto gráfico de conhecimento façamos, ainda temos RDF.
Outro exemplo é o Serviço de Consulta ao Histórico do Wikidata , que apareceu há alguns meses atrás. Antes de sua aparição, o Wikidata tinha que acessar a API Mediawiki padrão através do MWAPI . Agora, muito é possível no SPARQL puro. "Under the hood" também existe o RocksDB. A propósito, o WDHQS fez, ao que parece, a pessoa que importou o Freebase para o Google Knowledge Graph.
V. Suporte a GPL
Deixe-me lembrá-lo da principal diferença entre gráficos de GPL e RDF .
No LPG, as propriedades escalares podem ser suspensas nas instâncias de borda, enquanto no RDF elas podem ser suspensas apenas nos "tipos" de arestas (mas não apenas nas propriedades escalares, mas também nas relações regulares). Essa limitação do RDF em comparação ao GLP é superada por várias técnicas de modelagem. As limitações do GLP em comparação com o RDF são mais difíceis de superar, mas os gráficos de GLP são maiores que os gráficos de RDF, semelhantes às figuras do livro de texto da Harari, para que as pessoas os desejem.
Obviamente, a tarefa de apoiar o GPL se divide em duas partes:
- introdução de alterações no modelo RDF que permitam simular construções de GLP nele;
- fazendo alterações na linguagem de consulta RDF que permite acessar dados nesse modelo modificado ou a implementação da capacidade de fazer consultas nesse modelo em linguagens de consulta populares de GLP.
V.1 Modelos de dados
Existem várias abordagens possíveis.
V.1.1 Propriedade Singleton
A abordagem mais literal para harmonizar RDF e LPG é provavelmente a propriedade singleton :
- Em vez disso, por exemplo
:isMarriedTo , os predicados são usados :isMarriedTo1 , etc. - Esses predicados se tornam objetos de novos trigêmeos ::
:isMarriedTo1 :since "2013-09-13"^^xsd:date , etc. - O relacionamento dessas instâncias de predicados com um predicado comum é estabelecido por trigêmeos no formato
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo . - Obviamente,
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type , mas pense por que você não deve escrever simplesmente :isMarriedTo1 rdf:type :isMarriedTo .
A tarefa de dar suporte ao GLP é resolvida aqui no nível do RDFS. Essa solução requer inclusão no padrão relevante. Algumas alterações podem ser necessárias nos repositórios RDF que suportam efeitos de anexação, mas, por enquanto, a Propriedade Singleton pode ser tomada simplesmente como outra técnica de modelagem.
V.1.2 Reificação feita corretamente
Abordagens menos ingênuas resultam da constatação de que instâncias de propriedades são instanciadas por trigêmeos. Tendo a oportunidade de dizer algo sobre trigêmeos, temos a oportunidade de falar sobre instâncias de propriedades.
A mais sólida dessas abordagens é a RDF * , também conhecida como RDR, nascida nas entranhas do Blazegraph. Desde o início, a AnzoGraph o escolheu para si. A solidez da abordagem é determinada pelo fato de que dentro de sua estrutura as alterações correspondentes são propostas na RDF Semântica . O ponto, no entanto, é extremamente simples. Na serialização da tartaruga, o RDF agora pode ser escrito 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 suponha que os trigêmeos possuam determinados identificadores, que são, é claro, URIs e componham novos trigêmeos com esses URIs. Tudo o que resta é dar acesso a esses URIs no SPARQL. É isso que a Stardog faz.
O alegrógrafo foi um caminho intermediário. Sabe-se que existem identificadores triplos no Allegrograph, mas ao implementar atributos triplos, eles não se destacam. No entanto, a semântica formal está muito distante. Vale ressaltar que os atributos dos trigêmeos não são URIs, e os valores desses atributos também podem ser apenas literais. Os adeptos de GLP conseguem exatamente o que desejam. No formato NQX especialmente inventado, um exemplo semelhante ao acima para RDF * se parece com o seguinte:
:bob :marriedTo :alice {"since" : "2013-09-13"}
V.2 Idiomas de consulta
Tendo suportado o GPL de uma maneira ou de outra no nível do modelo, você precisa dar a oportunidade de fazer solicitações de dados nesse modelo.
- O Blazegraph para consultas RDF * suporta SPARQL * e Gremlin . A consulta para SPARQL * é assim:
SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }
- O Anzograph também suporta SPARQL * e suporta Cypher , uma linguagem de consulta no Neo4j.
- O Stardog suporta sua própria extensão SPARQL e novamente o Gremlin. Você pode obter tripletos e "meta-informações" no URI do SPARQL usando algo como isto:
SELECT * { BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id) ?id :since ?since }
- O Allegrograph também suporta sua própria extensão SPARQL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }
A propósito, o GraphDB já deu suporte ao Tinkerpop / Gremlin, embora não ao LPG, mas na versão 8.0 ou 8.1 isso parou.
VI Licenças mais restritas
Nenhuma adição na interseção dos conjuntos "triplestore of choice" e "open source triplestore" aconteceu recentemente. Os novos repositórios RDF de código aberto estão longe de ser uma boa opção para o uso diário, e o código fonte dos novos triplicadores que gostaríamos de usar (o mesmo AnzoGraph) está fechado. Em vez disso, podemos falar de diminuições ...
Obviamente, o código-fonte aberto anteriormente não fecha, mas alguns repositórios de código-fonte aberto gradualmente não são mais considerados dignos de escolha. Virtuoso, que tem uma edição de código aberto, na minha opinião, está se afogando em bugs. O Blazegraph foi comprado pela AWS e formou a base do Amazon Netuno; agora não está claro se haverá pelo menos mais uma versão. Tudo o que resta é Jena ...
Se o código aberto não é muito importante, mas você só quer tentar, tudo também é menos otimista do que antes. Por exemplo:
- O Stardog para de distribuir a versão gratuita (no entanto, dobrou o período de teste da versão normal);
- no GraphDB Cloud , onde anteriormente você podia escolher um plano básico gratuito, o registro de novos usuários é suspenso.
Em geral, para o leigo médio de TI, o espaço está se tornando cada vez mais inacessível; seu desenvolvimento se torna o grande número de empresas.