Conformità agli standard SPARQL in Amazon Neptune

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Dopo aver elencato gli standard SPARQL applicabili, le seguenti sezioni forniscono dettagli specifici su come l'implementazione SPARQL di Neptune si estende o si discosta da tali standard.

Amazon Neptune è conforme ai seguenti standard nell'implementazione del linguaggio di query a grafo SPARQL.

Standard applicabili per SPARQL

Prefissi dello spazio dei nomi predefiniti in Neptune SPARQL

Neptune definisce i seguenti prefissi per impostazione predefinita per l'utilizzo nelle query SPARQL. Per ulteriori informazioni, vedere Prefixed Names (Nomi con prefisso) nella specifica SPARQL.

Grafo predefinito SPARQL e grafi denominati

Amazon Neptune associa ogni tripla a un grafo denominato. Il grafo predefinito è definito come l'unione di grafi denominati.

Grafico predefinito per query

Se invii una query SPARQL senza specificare un grafo in maniera esplicita tramite la parola chiave GRAPH o costrutti quali FROM NAMED, Neptune considera sempre tutte le triple nell'istanza database. Ad esempio, la seguente query restituisce tutte le triple da un endpoint SPARQL Neptune:

SELECT * WHERE { ?s ?p ?o }

Le triple che appaiono in più grafici vengono restituite una sola volta.

Per informazioni sulla specifica del grafico predefinito, consulta la sezione RDF Dataset delle specifiche SPARQL 1.1 Query Language.

Specifica del grafo denominato per caricamento, inserimenti o aggiornamenti

Se non specifichi un grafo denominato durante il caricamento, l'inserimento o l'aggiornamento di triple, Neptune utilizza il grafo denominato di fallback definito dall'URI http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph.

Quando invii una richiesta Load Neptune utilizzando un formato basato sulla tripla, puoi specificare il grafo nominato da utilizzare per tutte le triple utilizzando il parametro parserConfiguration: namedGraphUri. Per ulteriori informazioni sulla sintassi del comando Load, consulta Comando dello strumento di caricamento Neptune.

Questo grafo di fallback denominato viene anche utilizzato se carichi triple tramite SPARQL UPDATE senza fornire in maniera esplicita una destinazione del grafo denominato.

Puoi utilizzare il formato basato su quadruple N-Quads per specificare un grafo denominato per ogni tripla nel database.

Funzioni del XPath costruttore SPARQL supportate da Neptune

Lo standard SPARQL consente ai motori SPARQL di supportare un set estensibile di funzioni di costruzione. XPath Neptune attualmente supporta le seguenti funzioni costruttore, dove il prefisso xsd è definito come http://www.w3.org/2001/XMLSchema#:

IRI di base predefinito per query e aggiornamenti

Poiché un cluster Neptune ha diversi endpoint, l'utilizzo dell'URL di richiesta di una query o di un aggiornamento come IRI di base potrebbe portare a risultati imprevisti durante la risoluzione relativa. IRIs

A partire dal rilascio 1.2.1.0 del motore, Neptune utilizza http://aws.amazon.com/neptune/default/ come IRI di base se un IRI di base esplicito non fa parte della richiesta.

Nella richiesta seguente, l'IRI di base fa parte della richiesta:

BASE <http://example.org/default/>
INSERT DATA { <node1> <id> "n1" }

BASE <http://example.org/default/>
SELECT * { <node1> ?p ?o }

E il risultato sarà:

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

In questa richiesta, tuttavia, non è incluso alcun IRI di base:

INSERT DATA { <node1> <id> "n1" }

SELECT * { <node1> ?p ?o }

In tal caso, il risultato sarà:

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

Valori xsd:dateTime in Neptune

Per motivi di prestazioni, Neptune archivia sempre i valori di data/ora come Tempo coordinato universale (UTC). Questo rende i confronti diretti molto efficienti.

Ciò significa anche che se si immette un valore dateTime che specifica un particolare fuso orario, Neptune converte il valore in formato UTC ed elimina le informazioni sul fuso orario. Quindi, quando si recupera il valore dateTime in un secondo momento, viene espresso in formato UTC, non l'ora del fuso orario originale e non è più possibile risalire al fuso orario originale.

Gestione di Neptune dei valori speciali a virgola mobile

Neptune gestisce i valori speciali a virgola mobile in SPARQL nel seguente modo:

Gestione del valore NaN di SPARQL in Neptune

In Neptune, SPARQL può accettare un valore NaN in una query. Non viene fatta alcuna distinzione tra valori NaN di segnalazione e silenziosi. Neptune considera tutti i valori NaN come silenziosi.

Dal punto di vista semantico, non è possibile un confronto di un valore NaN poiché non esistono elementi maggiori di, minori di o uguali a un valore NaN. Ciò significa che un valore NaN su un lato di un confronto in teoria non corrisponde mai a qualcosa sull'altro lato.

Tuttavia, la specifica XSD considera due valori NaN xsd:double o xsd:float come valori uguali. Neptune segue questo principio per il filtro IN, per l'operatore equal nelle espressioni di filtro e per la semantica di corrispondenza esatta (avendo un valore NaN nella posizione dell'oggetto di un modello di tripla).

Gestione del valore infinito di SPARQL in Neptune

In Neptune, SPARQL può accettare un valore INF o -INF in una query. INF viene confrontato come maggiore di qualsiasi altro valore numerico e -INF viene confrontato come minore di qualsiasi altro valore numerico.

Due valori INF con segni corrispondenti si confrontano come uguali tra loro indipendentemente dal loro tipo (ad esempio, un float -INF confronta come uguale a un doppio -INF).

Non è possibile un confronto con un valore NaN ovviamente poiché non esistono elementi maggiori di, minori di o uguali a un valore NaN.

Gestione dello zero negativo di SPARQL in Neptune

Neptune normalizza un valore zero negativo a uno zero senza segno. È possibile utilizzare i valori zero negativo in una query, ma non vengono registrati come tali nel database e vengono confrontati come uguali a zero senza segno.

Limitazione di Neptune dei valori di lunghezza arbitraria

Neptune limita la dimensione di archiviazione dei valori interi XSD, dei valori a virgola mobile e dei valori decimali in SPARQL a 64 bit. L'utilizzo di valori più grandi genera un errore InvalidNumericDataException.

Neptune estende il confronto di uguaglianza in SPARQL

Lo standard SPARQL definisce una logica ternaria per le espressioni di valore, in cui un'espressione di valore può restituire true, false, o error. La semantica predefinita per l'uguaglianza dei termini definita nella specifica SPARQL 1.1, che si applica ai confronti = e != nelle condizioni FILTER, produce un error quando si confrontano tipi di dati che non sono esplicitamente comparabili nella tabella degli operatori nella specifica.

Questo comportamento può portare a risultati non intuitivi, come nell'esempio seguente.

Dati:

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

Query 1:

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

Query 2:

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

Con la semantica SPARQL predefinita utilizzata da Neptune prima del rilascio 1.0.2.1, entrambe le query restituiranno il risultato vuoto. Il motivo è che ?o = "127.0.0.2"^^<http://example.com/IPAddress> quando viene valutato per ?o := "127.0.0.1"^^<http://example.com/IPAddress>, produce un error anziché false perché non esistono regole di confronto esplicite specificate per il tipo di dati personalizzato <http://example.com/IPAddress>. Di conseguenza, anche la versione negata nella seconda query produce un error. In entrambe le query, l'error causa il filtraggio della soluzione candidata.

A partire dal rilascio 1.0.2.1, Neptune ha esteso l'operatore di disuguaglianza SPARQL in accordo con le specifiche. Vedere la sezione SPARQL 1.1 sull'estensibilità dell'operatore, che consente ai motori di definire regole aggiuntive su come eseguire il confronto tra tipi di dati incorporati definiti dall'utente e non comparabili.

Utilizzando questa opzione, Neptune ora tratta un confronto di due tipi di dati che non è esplicitamente definito nella tabella di mappatura dell'operatore come se restituisse true, se i valori letterali e i tipi di dati sono sintatticamente uguali, altrimenti, false. In ogni caso, non viene prodotto un error.

Usando queste nuove semantiche, la seconda query restituirebbe "127.0.0.1"^^<http://example.com/IPAddress> invece di un risultato vuoto.

Gestione dei Out-of-Range valori letterali in Neptune SPARQL

La semantica XSD definisce ogni tipo numerico con il suo spazio valore, ad eccezione di integer e decimal. Queste definizioni limitano ogni tipo a un intervallo di valori. Ad esempio, l'intervallo di un intervallo xsd:byte è compreso tra -128 e +127, inclusi. Qualsiasi valore al di fuori di questo intervallo è considerato non valido.

Se si tenta di assegnare un valore letterale al di fuori dello spazio dei valori di un tipo (ad esempio, se si tenta di impostare an su un xsd:byte valore letterale di 999), Neptune accetta il valore così com'è, senza arrotondarlo o out-of-range troncarlo. Ma non lo mantiene come valore numerico perché il tipo fornito non può rappresentarlo.

Cioè, Neptune accetta "999"^^xsd:byte anche se è un valore al di fuori dell'intervallo di valori xsd:byte definito. Tuttavia, dopo che il valore viene mantenuto nel database, può essere utilizzato solo nella semantica di corrispondenza esatta, in una posizione oggetto di un modello triplo. Nessun filtro di intervallo può essere eseguito su di esso perché i valori letterali non vengono trattati come valori numerici. out-of-range

La specifica SPARQL 1.1 definisce gli operatori di intervallo nel formato numeric-operator-numeric, string-operator-string, literal-operator-literal e così via. Neptune non può eseguire un operatore di confronto di intervalli simile a invalid-literal-operator-numeric-value.