SPARQLconformidade com padrões no Amazon Neptune - Amazon Neptune

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

SPARQLconformidade com padrões no Amazon Neptune

Depois de listar SPARQL os padrões aplicáveis, as seções a seguir fornecem detalhes específicos sobre como a SPARQL implementação do Neptune se estende ou diverge desses padrões.

O Amazon Neptune está em conformidade com os seguintes padrões na implementação SPARQL da linguagem de consulta gráfica.

Padrões aplicáveis para SPARQL

Prefixos de namespace padrão em Neptune SPARQL

O Neptune define os seguintes prefixos por padrão para uso em consultas. SPARQL Para obter mais informações, consulte Nomes prefixados na SPARQL especificação.

  • rdf  – http://www.w3.org/1999/02/22-rdf-syntax-ns#

  • rdfs – http://www.w3.org/2000/01/rdf-schema#

  • owl  – http://www.w3.org/2002/07/owl#

  • xsd  – http://www.w3.org/2001/XMLSchema#

SPARQLGráfico padrão e gráficos nomeados

O Amazon Neptune associa cada triplo a um grafo nomeado. O gráfico padrão é definido como a união de todos os gráficos nomeados.

Gráfico padrão para consultas

Se você enviar uma SPARQL consulta sem especificar explicitamente um gráfico por meio da GRAPH palavra-chave ou de construções como, o FROM NAMED Neptune sempre considera todas as triplas em sua instância de banco de dados. Por exemplo, a consulta a seguir retorna todas as triplas de um endpoint do NeptuneSPARQL:

SELECT * WHERE { ?s ?p ?o }

Trios que aparecem em mais de um gráfico são retornados somente uma vez.

Para obter informações sobre a especificação padrão do gráfico, consulte a seção RDFConjunto de dados da especificação SPARQL 1.1 Query Language.

Especificar o gráfico nomeado para carregamentos, inserções ou atualizações

Se você não especificar um gráfico nomeado ao carregar, inserir ou atualizar triplos, o Neptune usa o gráfico alternativo chamado definido pelo. URI http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph

Ao emitir uma solicitação Load do Neptune usando um formato baseado em triplos, é possível especificar o grafo nomeado a ser usado para todos os triplos com o parâmetro parserConfiguration: namedGraphUri. Para obter mais informações sobre a sintaxe do comando Load, consulte Comando do carregador do Neptune.

Importante

Se você não usar esse parâmetro e não especificar um gráfico nomeado, o fallback URI será usado:http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph.

Esse gráfico nomeado de fallback também será usado se você carregar trios por meio de SPARQL UPDATE sem fornecer explicitamente um destino de gráfico nomeado.

Você pode usar o formato com base em quads, N-Quads, para especificar um gráfico nomeado para cada trio no banco de dados.

nota

O uso de N-Quads permite que você deixe o gráfico nomeado em branco. Nesse caso, http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph é usado.

Você pode substituir o gráfico padrão nomeado para N-Quads usando a opção de configuração do analisador namedGraphUri.

SPARQLXPathFunções de construtor suportadas pelo Neptune

O SPARQL padrão permite que SPARQL os motores suportem um conjunto extensível de funções do XPath construtor. No momento, o Neptune é compatível com as seguintes funções de construtor, nas quais o prefixo xsd é definido como http://www.w3.org/2001/XMLSchema#:

  • xsd:boolean

  • xsd:integer

  • xsd:double

  • xsd:float

  • xsd:decimal

  • xsd:long

  • xsd:unsignedLong

Base padrão IRI para consultas e atualizações

Como um cluster do Neptune tem vários endpoints diferentes, usar a URL solicitação de uma consulta ou atualização como IRI base pode levar a resultados inesperados na resolução relativa. IRIs

A partir da versão 1.2.1.0 do motor, o Neptune usa http://aws.amazon.com/neptune/default/ como base IRI se uma base explícita não fizer parte da IRI solicitação.

Na solicitação a seguir, a base IRI faz parte da solicitação:

BASE <http://example.org/default/> INSERT DATA { <node1> <id> "n1" } BASE <http://example.org/default/> SELECT * { <node1> ?p ?o }

E o resultado seria:

?p ?o http://example.org/default/id n1

Nessa solicitação, no entanto, nenhuma base IRI está incluída:

INSERT DATA { <node1> <id> "n1" } SELECT * { <node1> ?p ?o }

Nesse caso, o resultado seria:

?p ?o http://aws.amazon.com/neptune/default/id n1

xsd: dateTime Valores em Netuno

Por motivos de desempenho, o Neptune sempre armazena valores de data/hora como Tempo Universal Coordenado (). UTC Isso torna as comparações diretas muito eficientes.

Isso também significa que, se você inserir um dateTime valor que especifica um fuso horário específico, Neptune converte o valor UTC em e descarta essas informações de fuso horário. Então, quando você recupera o dateTime valor posteriormente, ele é expresso emUTC, não na hora do fuso horário original, e você não pode mais dizer qual era esse fuso horário original.

Tratar valores de ponto flutuante especiais do Neptune

Neptune manipula valores especiais de ponto flutuante da seguinte forma. SPARQL

SPARQLManuseamento de NaN em Neptune

Em NeptuneSPARQL, pode aceitar um valor NaN de em uma consulta. Não há distinção entre valores de NaN de sinalização e silenciosos. O Neptune trata todos os valores NaN como silenciosos.

Semanticamente, não é possível realizar uma comparação com um NaN, pois nada é maior que, menor que, nem igual a um NaN. Isso significa que um valor de NaN em um lado de uma comparação, teoricamente, nunca corresponde a nada do outro lado.

No entanto, a XSDespecificação trata dois xsd:double ou xsd:float NaN valores como iguais. O Neptune aplica isso ao filtro IN, para o operador igual em expressões de filtro e para a semântica de correspondência exata (com NaN na posição do objeto para um padrão triplo).

SPARQLManipulação de valores infinitos em Neptune

Em NeptuneSPARQL, pode aceitar um valor INF de -INF ou em uma consulta. INFcompara como maior do que qualquer outro valor numérico e -INF compara como menor do que qualquer outro valor numérico.

Dois INF valores com sinais correspondentes são comparados como iguais entre si, independentemente do tipo (por exemplo, um flutuador -INF se compara como igual a um duplo-INF).

Claro, não é possível realizar uma comparação com um NaN, pois nada é maior que, menor que, nem igual a um NaN.

SPARQLTratamento de zero negativo em Netuno

O Neptune normaliza um valor de zero negativo para um zero sem sinal. Você pode usar valores de zero negativo em uma consulta, mas eles não são registrados dessa forma no banco de dados, pois são comparados como iguais a zeros sem sinal.

Limitação de valores de comprimento arbitrário do Neptune

Neptune limita o tamanho de armazenamento de valores inteiros, XSD de ponto flutuante e decimais em 64 bits. SPARQL O uso de valores maiores gera um erro InvalidNumericDataException.

Neptune Extends Equals Comparation em SPARQL

O SPARQL padrão define uma lógica ternária para expressões de valor, em que uma expressão de valor pode ser avaliada como truefalse, ou. error A semântica padrão para igualdade de termos (conforme definida na especificação SPARQL 1.1), que se aplica a condições = e != comparações em FILTER condições, produz um error ao comparar tipos de dados que não são explicitamente comparáveis na tabela de operadores na especificação.

Esse comportamento pode levar a resultados não intuitivos, conforme o exemplo a seguir.

Dados:

<http://example.com/Server/1> <http://example.com/ip> "127.0.0.1"^^<http://example.com/datatype/IPAddress>

Consulta 1:

SELECT * WHERE { <http://example.com/Server/1> <http://example.com/ip> ?o . FILTER(?o = "127.0.0.2"^^<http://example.com/datatype/IPAddress>) }

Consulta 2:

SELECT * WHERE { <http://example.com/Server/1> <http://example.com/ip> ?o . FILTER(?o != "127.0.0.2"^^<http://example.com/datatype/IPAddress>) }

Com a SPARQL semântica padrão que o Neptune usava antes da versão 1.0.2.1, ambas as consultas retornariam o resultado vazio. O motivo é que ?o = "127.0.0.2"^^<http://example.com/IPAddress> quando avaliado para ?o := "127.0.0.1"^^<http://example.com/IPAddress> gera um error em vez de false, porque não há regras de comparação explícitas especificadas para o tipo de dados personalizado <http://example.com/IPAddress>. Como resultado, a versão negada na segunda consulta também gera um error. Em ambas as consultas, o error faz com que a solução candidata seja filtrada.

A partir da versão 1.0.2.1, o Neptune estendeu o operador de SPARQL desigualdade de acordo com a especificação. Consulte a seção SPARQL 1.1 sobre extensibilidade do operador, que permite que os mecanismos definam regras adicionais sobre como comparar entre tipos de dados integrados definidos pelo usuário e não comparáveis.

Ao usar essa opção, o Neptune trata uma comparação entre dois tipos de dados que não estão explicitamente definidos na tabela de mapeamento do operador como true, se os valores literais e os tipos de dados forem sintaticamente iguais, e falsos, caso não sejam. Um error não será produzido nesses casos.

Ao usar essas nova semânticas, a segunda consulta retornaria um "127.0.0.1"^^<http://example.com/IPAddress> em vez de um resultado vazio.

Manipulação de Out-of-Range literais em Netuno SPARQL

XSDa semântica define cada tipo numérico com seu espaço de valores, exceto e. integer decimal Essas definições limitam todos os tipos a um intervalo de valores. Por exemplo, um intervalo de xsd:byte é de -128 a +127, inclusivo. Qualquer valor fora desse intervalo é considerado inválido.

Se você tentar atribuir um valor literal fora do espaço de valor de um tipo (por exemplo, se tentar definir an xsd:byte como um valor literal de 999), Netuno aceitará o valor como está, sem arredondá-lo ou truncá-lo. out-of-range Mas ele não continua como um valor numérico, porque o tipo determinado não pode representá-lo.

Ou seja, o Neptune aceita "999"^^xsd:byte mesmo estando fora do intervalo de valores xsd:byte definido. No entanto, após o valor continuar no banco de dados, ele poderá ser usado somente na semântica de correspondência exata, em uma posição do objeto de um padrão triplo. Nenhum filtro de intervalo pode ser executado nele porque out-of-range os literais não são tratados como valores numéricos.

A especificação SPARQL 1.1 define operadores de intervalo no formato numeric -operador-numeric, string -operador-string, literal -operador- e assim por literal diante. O Neptune não pode executar um operador de comparação de intervalo como invalid-literal-operator-numeric-value.