Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Formats de chargement de données L'API Amazon Neptune `Load` permet le chargement de données dans différents formats. **Formats de chargement de graphes de propriétés** Les données chargées dans l'un des formats de graphes de propriétés suivants peuvent être interrogées à l'aide de Gremlin et d'openCypher : + [Format de chargement de données Gremlin](bulk-load-tutorial-format-gremlin.md) (`csv`) : format CSV (valeurs séparées par une virgule). + [Format de chargement de données openCypher (`opencypher`) :](bulk-load-tutorial-format-opencypher.md) format CSV (valeurs séparées par des virgules). **Formats de chargement RDF** Pour charger des données RDF (Resource Description Framework) à interroger avec SPARQL, vous pouvez utiliser l'un des formats standard suivants comme spécifié par W3C (World Wide Web Consortium) : + N-Triples (`ntriples`) de la spécification à l'adresse [https://www.w3.org/TR/n-triples/](https://www.w3.org/TR/n-triples/) + N-Quads (`nquads`) de la spécification à l'adresse [https://www.w3.org/TR/n-quads/](https://www.w3.org/TR/n-quads/) + RDF/XML (`rdfxml`) de la spécification à l'adresse [https://www.w3.org/TR/rdf-syntax-grammar/](https://www.w3.org/TR/rdf-syntax-grammar/) + Turtle (`turtle`) de la spécification à l'adresse [https://www.w3.org/TR/turtle/](https://www.w3.org/TR/turtle/) **Les données de chargement doivent utiliser l'encodage UTF-8** **Important** Tous les fichiers de chargement de données doivent être encodés au format UTF-8. Si un fichier n'est pas au format UTF-8, Neptune essaie de le charger dans ce format. Pour les données N-Quads et N-triples comprenant des caractères Unicode, les séquences d'échappement `\uxxxxx` sont prises en charge. Toutefois, Neptune ne prend pas en charge la normalisation. Si une valeur nécessitant une normalisation est présente, elle ne correspondra pas byte-to-byte lors de la requête. Pour plus d'informations sur la normalisation, consultez la page [Normalization](https://unicode.org/faq/normalization.html) sur [Unicode.org](https://unicode.org). Si vos données ne sont pas dans un format pris en charge, vous devez les convertir avant de les charger. Un outil permettant de convertir GraphML au format Neptune CSV est disponible dans le projet [Graph ML2](https://github.com/awslabs/amazon-neptune-tools/blob/master/graphml2csv/README.md) CSV sur. [GitHub](https://github.com/) ## Prise en charge de la compression des fichiers de chargement de données Neptune prend en charge la compression des fichiers individuels au format `gzip` ou `bzip2`. Le fichier compressé doit avoir une extension `.gz` ou `.bz2` et doit être un fichier texte encodé unique au format UTF-8. Vous pouvez charger plusieurs fichiers, mais chacun d'entre eux doit être un fichier `.gz`, `.bz2` ou non compressé distinct. Les fichiers d'archive portant des extensions telles que `.tar`, `.tar.gz` et `.tgz` ne sont pas pris en charge. Les sections suivantes décrivent les formats de façon plus détaillée. **Topics** + [Prise en charge de la compression des fichiers de chargement de données](#bulk-load-tutorial-format-compression) + [Format de chargement de données Gremlin](bulk-load-tutorial-format-gremlin.md) + [Format de chargement des données openCypher](bulk-load-tutorial-format-opencypher.md) + [Formats de chargement de données RDF](bulk-load-tutorial-format-rdf.md) # Format de chargement de données Gremlin Pour charger des données TinkerPop Apache G705 au format CSV, vous devez spécifier les sommets et les arêtes dans des fichiers séparés. Le chargeur peut effectuer le chargement depuis plusieurs fichiers de sommet et plusieurs fichiers d'arc en une seule tâche de chargement. Pour chaque commande de chargement, l'ensemble de fichiers à charger doit être dans le même dossier au sein du compartiment Amazon S3, et vous devez spécifier le nom du dossier pour le paramètre `source`. Les noms de fichier et les extensions de nom de fichier ne sont pas importants. Le format CSV Amazon Neptune respecte la spécification CSV RFC 4180. Pour plus d'informations, consultez [Common Format and MIME Type for CSV Files](https://tools.ietf.org/html/rfc4180) sur le site web Internet Engineering Task Force (IETF). **Note** Tous les fichiers doivent être encodés au format UTF-8. Chaque fichier comporte une ligne d'en-têtes séparés par des virgules. La ligne d'en-tête se compose d'en-têtes de colonne système et d'en-têtes de colonne de propriété. ## En-têtes de colonne système Les en-têtes de colonne système obligatoires et autorisés sont différents pour les fichiers de sommet et les fichiers d'arc. Chaque colonne système ne peut apparaître qu'une seule fois dans un en-tête. Toutes les étiquettes sont sensibles à la casse. **En-têtes de sommet** + `~id` - **Obligatoire** Un ID pour le sommet. + `~label` Une étiquette pour le sommet. Plusieurs valeurs d'étiquette sont autorisées, séparées par des points-virgules (`;`). S'il n'`~label`est pas présent, TinkerPop fournit une étiquette avec la valeur`vertex`, car chaque sommet doit avoir au moins une étiquette. **En-têtes d'arc** + `~id` - **Obligatoire** Un ID pour l'arc. + `~from` - **Obligatoire** ID de sommet du sommet *from*. + `~to` - **Obligatoire** ID de sommet du sommet *to*. + `~label` Étiquette de l'arête. Les arêtes ne peuvent avoir qu'une seule étiquette. S'il n'`~label`est pas présent, TinkerPop fournit une étiquette avec la valeur`edge`, car chaque arête doit avoir une étiquette. ## En-têtes de colonne de propriété Vous pouvez spécifier une colonne (`:`) pour une propriété à l'aide de la syntaxe suivante. Les noms de type ne sont pas sensibles à la casse. Notez toutefois que si le signe deux-points figure dans le nom d'une propriété, faites-le précéder d'une barre oblique inverse comme caractère d'échappement : `\:`. ``` propertyname:type ``` **Note** Les espaces, les virgules, le retour en chariot et les caractères de nouvelle ligne ne sont pas autorisés dans les en-têtes de colonne. Les noms de propriétés ne peuvent donc pas inclure ces caractères. Vous pouvez spécifier une colonne pour un type de tableau en ajoutant `[]` au type : ``` propertyname:type[] ``` **Note** Les propriétés d'arc ne peuvent avoir qu'une seule valeur et provoquent une erreur si un type de tableau ou une seconde valeur est spécifié. L'exemple suivant montre l'en-tête de colonne pour une propriété nommée `age` de type `Int`. ``` age:Int ``` Chaque ligne du fichier doit obligatoirement avoir un nombre entier dans cette position ou rester vide. Les tableaux de chaînes sont autorisés, mais les chaînes d'un tableau ne peuvent pas inclure le point-virgule (`;`), à moins qu'une barre oblique inverse n'y soit ajoutée comme caractère d'échappement (`\;`, par exemple). **Spécification de la cardinalité d'une colonne** L'en-tête de colonne peut être utilisé pour spécifier la *cardinalité* pour la propriété identifiée par la colonne. Ceci permet au chargeur en bloc de respecter la cardinalité de manière similaire à la façon dont le font les requêtes Gremlin. Vous spécifiez la cardinalité d'une colonne comme suit : ``` propertyname:type(cardinality) ``` La *cardinality* valeur peut être `single` soit`set`. La valeur par défaut est supposée être `set`, ce qui signifie que la colonne peut accepter plusieurs valeurs. Dans le cas des fichiers d'arête, la cardinalité est toujours unique (« single ») et si vous spécifiez une autre cardinalité, le chargeur déclenche une exception. Si la cardinalité est `single`, le chargeur déclenche une erreur si une valeur précédente est déjà présente pendant le chargement d'une valeur ou si plusieurs valeurs sont chargées. Ce comportement peut être ignoré afin qu'une valeur existante soit remplacée lorsqu'une nouvelle valeur est chargée à l'aide de l'indicateur `updateSingleCardinalityProperties`. Consultez [Commande Loader](load-api-reference-load.md). Il est possible d'utiliser un paramètre de cardinalité de type tableau, même si ce n'est généralement pas nécessaire. Voici les combinaisons possibles : + `name:type` : la cardinalité est `set`, et le contenu est à valeur unique. + `name:type[]` : la cardinalité est `set`, et le contenu est à valeurs multiples. + `name:type(single)` : la cardinalité est `single`, et le contenu est à valeur unique. + `name:type(set)` : la cardinalité est `set`, ce qui est identique à la valeur par défaut, et le contenu est à valeur unique. + `name:type(set)[]` : la cardinalité est `set`, et le contenu est à valeurs multiples. + `name:type(single)[]` : ce paramètre est contradictoire et génère une erreur. La section suivante répertorie tous les types de données Gremlin disponibles. ## Types de données Gremlin Il s'agit d'une liste des types de propriété autorisés, avec une description de chaque type. **Bool (ou booléen)** Indique un champ booléen. Valeurs autorisées : `false`, `true` **Note** Toute valeur autre que `true` sera traitée comme false. **Types de nombres entiers** Les valeurs en dehors des plages définies entraînent une erreur. | | | Type | Range | | --- |--- | | Octet | -128 à 127 | | Court | -32768 à 32767 | | Int | -2^31 à 2^31-1 | | Long | -2^63 à 2^63-1 | **Types de nombre décimal** Prend en charge la notation décimale ou la notation scientifique. Autorise également les symboles tels que (\$1/-) Infinity ou NaN. La clause INF n'est pas prise en charge. | | | Type | Range | | --- |--- | | Float | Virgule flottante IEEE 754 32 bits | | Double | Virgule flottante IEEE 754 64 bits | Les valeurs à virgule flottante et doubles qui sont trop longues sont chargées et arrondie à la valeur la plus proche pour la précision 24 bits (virgule flottante) et 53 bits (double). Une valeur du milieu est arrondie à 0 pour le dernier chiffre restant au niveau du bit. **String** Les guillemets sont facultatifs. Les virgules, et les caractères de saut de ligne et de retour à la ligne font automatiquement l'objet d'un échappement s'ils sont inclus dans une chaîne entourée de guillemets (`"`). *Exemple* : `"Hello, World"` Pour inclure des guillemets dans une chaîne entre guillemets, vous pouvez échapper les guillemets en utilisant deux guillemets dans une ligne : *Exemple :* `"Hello ""World"""` Les tableaux de chaînes sont autorisés, mais les chaînes d'un tableau ne peuvent pas inclure le point-virgule (`;`), à moins qu'une barre oblique inverse n'y soit ajoutée comme caractère d'échappement (`\;`, par exemple). Si vous souhaitez placer des chaînes d'un tableau entre guillemets, vous devez entourer la totalité du tableau par un ensemble de guillemets. *Exemple* : `"String one; String 2; String 3"` **Date** Date Java au format ISO 8601. Supporte les formats suivants :`yyyy-MM-dd`,`yyyy-MM-ddTHH:mm`,`yyyy-MM-ddTHH:mm:ss`,`yyyy-MM-ddTHH:mm:ssZ`. Les valeurs sont converties en heure d'époque et stockées. **Datetime** Date Java au format ISO 8601. Supporte les formats suivants :`yyyy-MM-dd`,`yyyy-MM-ddTHH:mm`,`yyyy-MM-ddTHH:mm:ss`,`yyyy-MM-ddTHH:mm:ssZ`. Les valeurs sont converties en heure d'époque et stockées. ## Format de ligne Gremlin **Délimiteurs** Les champs dans une ligne sont séparés par une virgule. Les enregistrements sont séparés par un saut de ligne ou par un saut de ligne suivi d'un retour chariot. **Champs vides** Des champs vides sont autorisés pour les colonnes non obligatoires (comme des propriétés définies par l'utilisateur). Un champ vide a quand même besoin d'une virgule comme séparateur. Les champs vides sur les colonnes obligatoires entraîneront une erreur d'analyse. Les valeurs de chaîne vides sont interprétées comme des valeurs de chaîne vides pour le champ, et non comme un champ vide. L'exemple de la section suivante comporte un champ vide dans chaque exemple de sommet. **Sommet IDs** Les valeurs `~id` doivent être uniques pour tous les sommets dans chaque fichier de sommets. Plusieurs lignes de sommet avec des valeurs `~id` identiques sont appliquées à un seul sommet dans le graphique. Une chaîne vide (`""`) est un identifiant valide, et le sommet est créé avec une chaîne vide comme identifiant. **Bord IDs** En outre, les valeurs `~id` doivent être uniques pour toutes les arêtes dans chaque fichier d'arête. Plusieurs lignes d'arête avec des valeurs `~id` identiques sont appliquées à la seule arête du graphe. La chaîne vide (`""`) est un identifiant valide, et le bord est créé avec une chaîne vide comme identifiant. **Étiquettes** Les étiquettes distinguent les majuscules et minuscules et ne peuvent pas être vides. Une valeur de `""` provoquera une erreur. **Valeurs de chaîne** Les guillemets sont facultatifs. Les virgules, et les caractères de saut de ligne et de retour à la ligne font automatiquement l'objet d'un échappement s'ils sont inclus dans une chaîne entourée de guillemets (`"`). `("")`Les valeurs de chaîne vides sont interprétées comme une valeur de chaîne vide pour le champ, et non comme un champ vide. ## Spécification du format CSV Le format CSV Neptune respecte la spécification CSV RFC 4180, y compris les exigences suivantes. + Les fins de ligne de style Unix et Windows sont prises en charge (\$1n ou \$1r\$1n). + Tout champ peut être placé entre guillemets. + Les champs contenant un saut de ligne, des guillemets ou des virgules doivent être placés entre guillemets. (Si ce n'est pas le cas, le chargement s'interrompt immédiatement.) + Les guillemets (`"`) dans un champ doit être représentés par des guillemets doubles. Par exemple, une chaîne `Hello "World"` doit figurer sous la forme `"Hello ""World"""` dans les données. + Les espaces entre les délimiteurs sont ignorés. Si une ligne est présente sous forme`value1, value2`, elle est stockée sous forme `"value1"` et`"value2"`. + Tous les autres caractères d'échappement sont stockés tels quels. Par exemple, `"data1\tdata2"` est stocké comme suit : `"data1\tdata2"`. Aucun autre échappement n'est nécessaire dans la mesure où ces caractères sont placés entre guillemets. + Les champs vides sont autorisés. Un champ vide est considéré comme une valeur vide. + Plusieurs valeurs pour un champ sont spécifiées séparées par un point-virgule (`;`). Pour plus d'informations, consultez [Common Format and MIME Type for CSV Files](https://tools.ietf.org/html/rfc4180) sur le site web Internet Engineering Task Force (IETF). ## Exemple Gremlin Le schéma suivant montre un exemple de deux sommets et d'une arête extraits du graphe TinkerPop moderne. ![\[Schéma décrivant deux sommets et une arête, contenant marko age 29 et le logiciel lop avec lang:java.\]](http://docs.aws.amazon.com/fr_fr/neptune/latest/userguide/images/tiny-modern-graph.png) Voici le graphe au format de chargement CSV Neptune. Fichier de sommets : ``` ~id,name:String,age:Int,lang:String,interests:String[],~label v1,"marko",29,,"sailing;graphs",person v2,"lop",,"java",,software ``` Vue tabulaire du fichier de sommets : | | | | | | | | --- |--- |--- |--- |--- |--- | | \$1id | name:String | age:Int | lang:String | Intérêts:string [] | \$1étiquette | | v1 | "marko" | 29 | | ["navigation », « graphes"] | personne | | v2 | "lop" | | "java" | | logiciel | Fichier d'arête : ``` ~id,~from,~to,~label,weight:Double e1,v1,v2,created,0.4 ``` Vue tabulaire du fichier d'arête : | | | | | | | --- |--- |--- |--- |--- | | \$1id | \$1de | \$1sur | \$1étiquette | weight:Double | | e1 | v1 | v2 | créé | 0.4 | **Étapes suivantes** Maintenant que vous en savez plus sur les formats de chargement, consultez [Exemple : chargement de données dans une instance de base de données Neptune](bulk-load-data.md). # Format de chargement des données openCypher Pour charger des données openCypher à l'aide du format CSV openCypher, vous devez spécifier les nœuds et les relations dans des fichiers séparés. Le chargeur peut charger les données à partir de plusieurs de ces fichiers de nœuds et fichiers de relations en une seule tâche de chargement. Pour chaque commande de chargement, l'ensemble de fichiers à charger doit avoir le même préfixe de chemin dans un compartiment Amazon Simple Storage Service. Vous spécifiez ce préfixe dans le paramètre source. Les noms et les extensions de fichier ne sont pas importants. Dans Amazon Neptune, le format CSV openCypher est conforme à la spécification CSV RFC 4180. Pour plus d'informations, consultez [Common Format et type MIME pour les fichiers CSV](https://tools.ietf.org/html/rfc4180) (https://tools.ietf.org/html/rfc4180) sur le site Web de l'Internet Engineering Task Force (IETF). **Note** Ces fichiers DOIVENT être encodés au format UTF-8. Chaque fichier possède une ligne d'en-têtes séparés par des virgules, qui contient à la fois les en-têtes de colonne système et les en-têtes de colonne des propriétés. ## En-têtes de colonne système dans les fichiers de chargement de données openCypher Une colonne système spécifique ne peut apparaître qu'une seule fois dans chaque fichier. Toutes les étiquettes d'en-tête de colonne système sont sensibles à la casse. Les en-têtes de colonne système obligatoires et autorisés sont différents pour les fichiers de chargement de nœuds et les fichiers de chargement de relations openCypher : ### En-têtes de colonnes système dans les fichiers de nœuds + **`:ID`** : (obligatoire) ID du nœud. Un espace d'ID facultatif peut être ajouté à l'en-tête de colonne du nœud `:ID` comme ceci : `:ID(ID Space)`. Par exemple : `:ID(movies)`. Lorsque vous chargez des relations qui connectent les nœuds de ce fichier, utilisez les mêmes espaces d'identification dans les `:START_ID` and/or `:END_ID` colonnes des fichiers de relations. La colonne du nœud `:ID` peut éventuellement être stockée en tant que propriété sous la forme `property name:ID`. Par exemple : `name:ID`. Le nœud IDs doit être unique parmi tous les fichiers de nœuds des chargements actuels et précédents. Si un espace d'identification est utilisé, le nœud IDs doit être unique parmi tous les fichiers de nœuds qui utilisent le même espace d'identification lors des chargements actuels et précédents. + **`:LABEL`** : étiquette du nœud. Lorsque vous utilisez plusieurs valeurs d'étiquette pour un seul nœud, chaque étiquette doit être séparée par des points-virgules (). `;` ### En-têtes de colonnes système dans les fichiers de relations + **`:ID`** : ID de la relation. Obligatoire lorsque `userProvidedEdgeIds` est défini sur true (valeur par défaut), mais non valide quand `userProvidedEdgeIds` indique `false`. La relation IDs doit être unique dans tous les fichiers de relations des chargements actuels et précédents. + **`:START_ID`** : (*obligatoire*) ID du nœud à partir duquel cette relation commence. Un espace d'ID peut être associé à la colonne d'ID de départ sous la forme `:START_ID(ID Space)`. L'espace d'ID attribué à l'ID du nœud de départ doit correspondre à l'espace d'ID attribué au nœud dans son fichier de nœud. + **`:END_ID`** : (*obligatoire*) ID du nœud où cette relation se termine. Un espace d'ID peut être associé à la colonne d'ID de fin sous la forme `:END_ID(ID Space)`. L'espace d'ID attribué à l'ID du nœud de fin doit correspondre à l'espace d'ID attribué au nœud dans son fichier de nœud. + **`:TYPE`** : type de relation. Les relations ne peuvent avoir qu'un seul type. **Note** Consultez [Chargement de données openCypher](load-api-reference-load.md#load-api-reference-load-parameters-opencypher) pour plus d'informations sur la façon dont les nœuds ou IDs les relations dupliqués sont gérés par le processus de chargement en bloc. ### En-têtes de colonnes de propriétés dans les fichiers de chargement de données openCypher Vous pouvez spécifier qu'une colonne contient les valeurs d'une propriété particulière à l'aide d'un en-tête de colonne de propriété sous la forme suivante : ``` propertyname:type ``` Les espaces, les virgules, le retour en chariot et les caractères de nouvelle ligne ne sont pas autorisés dans les en-têtes de colonne. Les noms de propriétés ne peuvent donc pas inclure ces caractères. Voici un exemple d'en-tête de colonne pour une propriété nommée `age` de type `Int` : ``` age:Int ``` La colonne avec `age:Int` comme en-tête de colonne devrait alors contenir un entier ou une valeur vide sur chaque ligne. ## Types de données dans les fichiers de chargement de données Neptune openCypher + **`Bool`** ou **`Boolean`** : champ booléen. Les valeurs autorisées sont `true` et `false`. Toute valeur autre que `true` qui est traitée comme `false`. + **`Byte`** : nombre entier compris entre `-128` et `127`. + **`Short`** : nombre entier compris entre `-32,768` et `32,767`. + **`Int`** : nombre entier compris entre `-2^31` et `2^31 - 1`. + **`Long`** : nombre entier compris entre `-2^63` et `2^63 - 1`. + **`Float`** : nombre à virgule flottante IEEE 754 32 bits. La notation décimale et la notation scientifique sont toutes deux prises en charge. `Infinity`, `-Infinity`, et `NaN` sont tous reconnus, mais pas `INF`. Les valeurs contenant trop de chiffres sont arrondies à la valeur la plus proche (une valeur intermédiaire est arrondie à 0 pour le dernier chiffre restant au niveau du bit). + **`Double`** : nombre à virgule flottante IEEE 754 64 bits. La notation décimale et la notation scientifique sont toutes deux prises en charge. `Infinity`, `-Infinity`, et `NaN` sont tous reconnus, mais pas `INF`. Les valeurs contenant trop de chiffres sont arrondies à la valeur la plus proche (une valeur intermédiaire est arrondie à 0 pour le dernier chiffre restant au niveau du bit). + **`String`** : les guillemets sont facultatifs. Les virgules et les caractères de saut de ligne et de retour à la ligne font automatiquement l'objet d'un échappement s'ils sont inclus dans une chaîne entourée de guillemets doubles (`"`) comme `"Hello, World"`. Vous pouvez inclure des guillemets dans une chaîne qui contient déjà des guillemets en utilisant deux guillemets d'affilée comme `"Hello ""World"""`. + **`DateTime`** : date Java dans l'un des formats ISO 8601 suivants : + `yyyy-MM-dd` + `yyyy-MM-ddTHH:mm` + `yyyy-MM-ddTHH:mm:ss` + `yyyy-MM-ddTHH:mm:ssZ` ### Types de données diffusées automatiquement dans les fichiers de chargement de données Neptune openCypher Les types de données diffusées automatiquement sont fournis pour charger des types de données qui ne sont pas actuellement pris en charge nativement par Neptune. Les données de ces colonnes sont stockées sous forme de chaînes, mot pour mot, sans vérification par rapport au format prévu. Voici les types de données diffusées automatiquement qui sont autorisés : + **`Char`** : champ `Char`. Stocké sous forme de chaîne. + **`Date`**, **`LocalDate`**, et **`LocalDateTime`** : consultez [Instants temporels Neo4j](https://neo4j.com/docs/cypher-manual/current/values-and-types/temporal/#cypher-temporal-instants) pour obtenir une description des types `date`, `localdate` et `localdatetime`. Les valeurs sont chargées telles quelles sous forme de chaînes, sans validation. + **`Duration`** : consultez le [format de durée Neo4j](https://neo4j.com/docs/cypher-manual/current/values-and-types/temporal/#cypher-temporal-durations). Les valeurs sont chargées telles quelles sous forme de chaînes, sans validation. + **Point** : champ de point destiné au stockage de données spatiales. Consultez [Instants spatiaux](https://neo4j.com/docs/cypher-manual/current/values-and-types/spatial/#spatial-values-spatial-instants). Les valeurs sont chargées telles quelles sous forme de chaînes, sans validation. ## Exemple de format de chargement openCypher Le schéma suivant, tiré du TinkerPop Modern Graph, montre un exemple de deux nœuds et d'une relation : ![\[Schéma de deux nœuds et d'une relation entre eux.\]](http://docs.aws.amazon.com/fr_fr/neptune/latest/userguide/images/tinkerpop-2-nodes-and-relationship.png) Voici le graphe au format de chargement Neptune openCypher normal. **Fichier de nœud :** ``` :ID,name:String,age:Int,lang:String,:LABEL v1,"marko",29,,person v2,"lop",,"java",software ``` **Fichier de relation :** ``` :ID,:START_ID,:END_ID,:TYPE,weight:Double e1,v1,v2,created,0.4 ``` Vous pouvez également utiliser les espaces d'ID et l'ID en tant que propriétés, comme suit : **Fichier du premier nœud :** ``` name:ID(person),age:Int,lang:String,:LABEL "marko",29,,person ``` **Fichier du deuxième nœud :** ``` name:ID(software),age:Int,lang:String,:LABEL "lop",,"java",software ``` **Fichier de relation :** ``` :ID,:START_ID(person),:END_ID(software),:TYPE,weight:Double e1,"marko","lop",created,0.4 ``` # Formats de chargement de données RDF Pour charger des données RDF (Resource Description Framework), vous pouvez utiliser l'un des formats standard suivants comme spécifié par W3C (World Wide Web Consortium) : + N-Triples (`ntriples`) de la spécification à l'adresse [https://www.w3.org/TR/n-triples/](https://www.w3.org/TR/n-triples/) + N-Quads (`nquads`) de la spécification à l'adresse [https://www.w3.org/TR/n-quads/](https://www.w3.org/TR/n-quads/) + RDF/XML (`rdfxml`) de la spécification à l'adresse [https://www.w3.org/TR/rdf-syntax-grammar/](https://www.w3.org/TR/rdf-syntax-grammar/) + Turtle (`turtle`) de la spécification à l'adresse [https://www.w3.org/TR/turtle/](https://www.w3.org/TR/turtle/) **Important** Tous les fichiers doivent être encodés au format UTF-8. Pour les données N-Quads et N-triples comprenant des caractères Unicode, les séquences d'échappement `\uxxxxx` sont prises en charge. Toutefois, Neptune ne prend pas en charge la normalisation. Si une valeur nécessitant une normalisation est présente, elle ne correspondra pas byte-to-byte lors de la requête. Pour plus d'informations sur la normalisation, consultez la page [Normalization](https://unicode.org/faq/normalization.html) sur [Unicode.org](https://unicode.org). **Étapes suivantes** Maintenant que vous en savez plus sur les formats de chargement, consultez [Exemple : chargement de données dans une instance de base de données Neptune](bulk-load-data.md).