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à.
# Modello di piscina per RDF
Il Resource Description Framework (RDF) ha il concetto di grafici denominati, che fornisce un modo logico per separare i dati. In Amazon Neptune, hai un grafico con nome predefinito e grafici denominati definiti dall'utente. Puoi creare tutti i grafici con nome che desideri. Collettivamente, sono chiamati set di dati RDF. Tutti i grafici denominati, predefiniti o definiti dall'utente, sono definiti da un Internationalized Resource Identifier (IRI) all'interno del set di dati RDF. In Neptune, a meno che un utente non abbia dichiarato un grafico con nome durante la scrittura dei dati, [tutte le](https://www.w3.org/TR/PR-rdf-syntax/#model) triple sono considerate parte del grafico denominato predefinito.
Esistono diversi casi d'uso per i grafici con nome:
+ Partizionamento e isolamento dei dati
+ Provenienza dei dati
+ Controllo delle versioni
+ Inferenza
Questa guida si concentra sul caso d'uso del partizionamento dei dati. Consigliamo di creare un grafico denominato definito dall'utente per ogni tenant.
## Opzioni di interrogazione SPARQL che utilizzano il protocollo HTTP Graph Store
Le seguenti query di esempio utilizzano il protocollo SPARQL e il linguaggio di interrogazione RDF (SPARQL) e il protocollo HTTP Graph Store per interrogare o creare un grafico denominato per un tenant.
+ `HTTP GET`‒ Per recuperare un grafico specifico di un tenant:
```
curl --request GET 'https://your-neptune-endpoint:port/sparql/gsp/?graph=http%3A//www.example.com/named/tenant1'
```
+ `HTTP PUT`‒ Per creare o sostituire uno specifico grafico denominato con un payload specificato nella richiesta:
```
curl --request PUT -H "Content-Type: text/turtle" \ --data-raw "@prefix ex: http://example.com/ . ex:subject ex:predicate ex:object ." \
'https://your-neptune-endpoint:port/sparql/gsp/?graph=http%3A//www.example.com/named/tenant1'
```
In RDF, un oggetto è triplo.
+ `HTTP POST`‒ Per creare un nuovo grafico con nome, se non ne esiste uno, o fonderlo con un grafo esistente:
```
curl --request POST -H "Content-Type: text/turtle" \
--data-raw "@prefix ex: http://example.com/ . ex:subject ex:predicate ex:object ." \
'https://your-neptune-endpoint:port/sparql/gsp/?graph=http%3A//www.example.com/named/tenant1'
```
## Isolamento dei tenant per RDF
Per l'isolamento logico dei dati con le necessarie protezioni a livello di applicazione, create una mappatura tra il tenant e i grafici denominati definiti dall'utente. [Quando progettate la multi-tenancy per un set di dati RDF, tenete presente i seguenti aspetti di RDF e SPARQL:](https://www.w3.org/TR/sparql11-query/)
+ In Neptune, quando si esegue una query senza specificare un grafico denominato, vengono recuperate tutte le triple che corrispondono al modello in tutti i grafici denominati nel database.
+ In RDF, non ci sono vincoli relativi alle connessioni tra nodi di grafici con nomi diversi. Ad esempio, nel diagramma precedente, un nodo in `:G1` può essere collegato a un nodo in: attraverso un bordo. `G2`
Ad esempio, se un utente finale di un determinato tenant invia una query all'API, l'API deve convalidare i seguenti requisiti prima di inviare la query al database Neptune:
+ Qualsiasi query con ambito a un singolo tenant deve specificare un grafico denominato. Altrimenti, rischi di far trapelare dati tra i tenant.
+ Le interrogazioni di aggiornamento o eliminazione devono sempre specificare un grafico denominato.
+ I nodi su entrambi i lati di uno spigolo o di una relazione devono sempre appartenere al grafico con nome corretto.
Per ulteriori informazioni sulle migliori pratiche, consulta la documentazione di [Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/feature-sparql-compliance.html).