Brevet FR2853977A1 — publié le 20041022

DOMAINE DE L'INVENTION La présente invention concerne le traitement de données d'un cadre de description de ressources. DESCRIPTION DE LA TECHNIQUE ASSOCIÉE Le cadre de description de ressources (RDF) est un langage destiné à représenter des informations et des ressources accessibles par l'intermédiaire du World Wide Web (WWW). De façon spécifique, un RDF est destiné à représenter des "metadata" concernant des ressources du Web, telles que le titre, l'auteur et des données de modification d'une page Web, des informations de droits d'auteur et de licence concernant un document Web, la disponibilité de certaines ressources partagées et/ou analogue. L'un des avantages du RDF est sa généralité. De façon spécifique, le RDF constitue un cadre commun pour exprimer des informations pour l'échange entre des applications sans perte de signification. En conséquence, le RDF n'est limité à aucun type d'objet particulier. Par exemple, le RDF peut également être utilisé pour identifier des informations concernant des éléments pouvant être identifiés sur le Web, même si ses éléments ne peuvent pas être directement récupérés sur le Web. Le RDF est basé sur l'idée consistant à identifier des objets ou des éléments en utilisant des identifiants du Web (URI) et décrire des ressources en termes de propriétés simples et de valeurs de propriétés. Ceci permet au RDF de représenter des instructions simples concernant des ressources sous la forme d'un graphe dirigé de noeuds représentant les ressources, leurs propriétés et leurs valeurs de propriétés. Le RDF utilise, en outre, une syntaxe à base de "extensible markup language" (XML) pour enregistrer et échanger ces graphes. D'autres améliorations concernant le RDF sont indiquées dans "RDF Primer", W3C Working Draft, 23 janvier 2003 (disponible sur http://www.w3.org/TR/2003/WD-rdf-primer-20030123/), qui est ici incorporé en référence. BREF RÉSUMÉ Dans un mode de réalisation, un système traite des données de cadre de description de ressources (RDF). Le système comprend une pluralité de schémas de RDF définissant des éléments de RDF et des relations entre certains des éléments de RDF, une mémoire de données de RDF pour mémoriser des triplets de RDF en conformité avec la pluralité de schémas de RDF, et un service de base de données de RDF pour recevoir les transactions de la base de données afin d'ajouter des triplets de RDF à la mémoire de données de RDF, dans lequel le service de base de données de RDF peut être activé pour valider un triplet de RDF par rapport à la pluralité de schémas de RDF avant d'introduire le triplet de RDF dans la mémoire de données de RDF. BRÈVE DESCRIPTION DES DESSINS La figure 1 est une représentation de données d'un graphe dirigé de RDF. La figure 2 est une représentation de données de triplets de RDF. La figure 3A représente une base de données de RDF selon des modes de réalisation représentatifs. Les figures 3B et 3C sont des organigrammes des déroulements des traitements pouvant être mis en oeuvre par une base de données de RDF selon des modes de réalisation représentatifs. La figure 4 représente un référentiel de RDF selon des modes de réalisation représentatifs. La figure 5 est un organigramme de traitement de transactions de méthodes de propriétés selon des modes de réalisation représentatifs. La figure 6 représente un générateur d'ensemble de codes de metadata qui exécutent un transcodage de données selon des modes de réalisation représentatifs. La figure 7 représente un système informatique adapté à mettre en oeuvre des modes de réalisation représentatifs. DESCRIPTION DÉTAILLÉE En se référant maintenant aux dessins, la figure 1 est une représentation de données 100 selon le modèle de RDF utilisé pour définir les relations de données. Le modèle de RDF fournit une méthodologie pour décrire les relations entre des objets identifiables du Web. De façon spécifique, le modèle de RDF définit les relations en utilisant un sujet, des prédicats et des objets mappés sur un graphe dirigé. Dans cet exemple, le modèle de RDF est utilisé pour décrire les caractéristiques d'une page Web (à savoir, le créateur, la date de création et la langue). De façon spécifique, la représentation de données 100 identifie un noeud 101 en utilisant un URI (http://www.example.org/home.htm). Le noeud 101 est un noeud sujet, dans ces relations, car la structure de graphe dirigé ne peut aller que du noeud sujet vers les autres noeuds. Les relations entre les noeuds sont respectivement définies par des prédicats 102, 103, 104 : "http://www.example.org/terms/creationdate", "http://www.example.org/terms/language", et "http://www.example.org/elements/1.1/creator". Des objets 105,106 et 107 définissent la valeur associée à la relation. Les valeurs peuvent être littérales, telles que "MARCH 3, 2003", et "ENGLISH" pour les objets 105 et 106. À titre de variante, les valeurs dans le modèle RDF peuvent être d'autres ressources identifiables du Web telles que l'objet 107, comme défini par "http://www.example.org/empid/147782". La figure 2 est une représentation de données 200 de la représentation de données 100 selon les notations de "triplets" de RDF. Chaque triplet possède un sujet, un prédicat et un objet respectif. Chaque triplet représente un trajet unique dans le graphe dirigé indiqué dans la représentation de données 100. La représentation de données 200 peut être mise en oeuvre selon un certain nombre de manières. Typiquement, la représentation de données 200 peut être codée avec des représentations XML. L'utilisation d'un graphe dirigé et d'identifiants du Web pour définir des relations de données est avantageuse pour un certain nombre de raisons. Premièrement, l'utilisation d'identifiants du Web (à la place de descripteurs littéraux statiques tels que "creation-date") permet de différencier les propriétés utilisées par une entité donnée des propriétés utilisées par une autre entité qui serait, dans le cas contraire, identifiée par le même nom. De plus, en utilisant un graphe dirigé, il est relativement direct d'étendre la description du sujet. Par exemple, il n'est pas nécessaire qu'une structure ou une classe de données prédéfinie soit définie de manière rigide pour représenter toutes les caractéristiques possibles du sujet 101. Le RDF ne définit pas la manière dont ces relations de données doivent être mémorisées. Plusieurs mises en oeuvre existent. Par exemple, des mises en oeuvre connues mappent le RDF vers une structure de base de données relationnelle qui peut être interrogée en utilisant des requêtes de langage d'interrogation standard (SQL). Toutefois, les bases de données relationnelles peuvent être problématiques pour la mémorisation de données de RDF. De façon spécifique, les bases de données relationnelles enregistrent et traitent des données dans la base de données conformément à un modèle de table. Ce modèle est différent du modèle de graphe dirigé utilisé par le RDF. Les différences peuvent produire des résultats inférieurs à l'optimum durant le remplissage de la base de données, la modification de la structure de la base de données et l'exécution d'autres activités de gestion de la base de données. De plus, le RDF ne fournit aucun mécanisme pour valider les valeurs enregistrées des objets en ce qui concerne les relations définies par les prédicats. De façon spécifique, "RDF Primer", W3C Working Draft, 23 janvier 2003, énonce que "lorsqu'un URIref identifie réellement un type de données, le RDF lui-même ne définit pas la validation de l'appariement de ce type de données avec une valeur littérale particulière. Cette validité ne peut être déterminée que par un logiciel conçu pour comprendre ce type de données". Le mécanisme pour définir un vocabulaire dans le RDF est appelé schéma de RDF. Un schéma de RDF permet à une entité particulière de définir des types de choses (par exemple, "creator", voir le prédicat 104), propriétés (par exemple, "creation-date", voir le prédicat 102), pour définir les types de chose pouvant servir de sujets ou d'objets (par exemple, en spécifiant que la valeur d'une propriété "âge" doit être représentée par un entier). Le schéma de RDF permet de définir des ressources comme étant des instances de classes (principalement de la même façon que la programmation orientée objet définit des classes). Les classes peuvent être structurées de façon hiérarchique. Dans un schéma de RDF, une classe est définie en fournissant une ressource ayant une propriété rdf:type dont la valeur est la ressource refs:Class définie par RDFS. Par exemple, une classe de contrat "real estate" doit être définie en utilisant . Un document particulier (par exemple, identifié par http ://www.example.org/warrantydeed.doc) peut être identifié comme étant une instance du contrat "real estate" par . Les ressources peuvent également être définies comme une instance de classes multiples d'une manière similaire. De plus, des sous-classes peuvent être définies d'une manière similaire. Les propriétés d'une classe peuvent être définies en affectant la propriété d'un URI et en décrivant cette ressource en utilisant rdf:Property. Pour définir la relation entre les propriétés et un type de données particulier (par exemple, une ressource telle que "employée"), on peut utiliser rdfs:range. La figure 3A représente une base de données de RDF selon des modes de réalisation représentatifs. La base de données de RDF 300 optimise avantageusement la mémorisation et/ou le traitement des données conformément au modèle de RDF. La base de données de RDF 300 diffère des structures de base de données connues en utilisant la conceptualisation de graphe dirigé du RDF pour mémoriser et traiter les données enregistrées dans la base de données. De plus, en utilisant le graphe dirigé comme modèle, la base de données de RDF 300 permet à un schéma supplémentaire de contraindre ou d'ouvrir davantage le modèle de données existant sans nécessiter de modification appréciable de la mémorisation physique des données natives de constitution. La base de données de RDF 300 comporte un service de base de données de RDF 301, qui peut être mis en oeuvre sous la forme d'un service accessible dans un environnement de serveur d'applications. Le service de base de données de RDF 301 peut être utilisé comme interface afin de recevoir des données de RDF pour coder la base de données, afin de recevoir des requêtes de base de données de RDF et afin de fournir des résultats en réponse aux requêtes de base de données de RDF. Le service de référentiel de RDF 302 du service de base de données de RDF 301 peut mettre en oeuvre les relations définies par le ou les schémas de RDF 305 pour les données enregistrées dans la ou les mémoires de données de RDF 303. Pour mettre en oeuvre les relations, le service de référentiel de RDF 302 fournit une vue unifiée d'un ou plusieurs schémas de RDF 305. De façon spécifique, le service de référentiel de RDF 302 utilise le modèle de graphe dirigé de RDF pour assembler une carte complète des relations définies par le ou les schémas de RDF 305. Ainsi, chaque relation, applicable à chaque ressource, classe, sous-classe, propriété et/ou analogue, peut être déterminée sur une base dynamique. En créant une vue unifiée convenable de schéma(s) de RDF 305, le service de référentiel de RDF 302 permet une extension et une adaptation souples du ou des schémas de RDF 305. Par exemple, les ensembles suivants de schémas peuvent être ajoutés au(x) schéma(s) de RDF 305. Les schémas supplémentaires peuvent imposer d'autres contraintes aux relations précédemment définies dans des ensembles de schémas antérieurs. Le service de référentiel de RDF 302 permet de mettre en oeuvre de façon dynamique ces contraintes supplémentaires en dépit du fait que la totalité des contraintes sont exprimées successivement dans des ensembles de schémas différents. Lorsque des données sont introduites dans la base de données en utilisant le modèle de RDF, les données peuvent être exprimées en termes d'une instruction de RDF (par exemple, un triplet de RDF). Le service de référentiel de RDF 302 peut examiner la relation définie par l'instruction de RDF par rapport aux contraintes exprimées par un ou plusieurs schémas parmi le ou les schémas de RDF 305, par l'intermédiaire de la vue unifiée du ou des schémas de RDF 305. Si l'instruction de RDF est cohérente avec les contraintes, l'instruction de RDF peut être enregistrée dans la base de données en mémorisant des données appropriées dans la ou les mémoires de données de RDF 303 et, ce qui est possible, en mettant à jour l'index/les indices de RDF 304. Si l'instruction de RDF est incohérente avec les contraintes, un état d'erreur peut être indiqué, maintenant ainsi l'intégrité des données de la base de données de RDF 300. Outre le maintien de l'intégrité des données, la base de données de RDF 300 peut utiliser, en outre, la structure de graphe des données de RDF pour optimiser le traitement des requêtes de base de données. Le service de base de données de RDF 301 peut organiser la mémorisation des données de RDF dans la ou les mémoires de données de RDF 303 conformément à une vue unifiée des données de RDF, principalement de la même façon que le service de référentiel de RDF 302 gère une vue unifiée du ou des schémas de RDF 305. En gérant une vue unifiée des données de RDF, une identification d'une ressource particulière permet de déterminer chaque instruction concernant la ressource en traversant les trajets individuels à partir de cette ressource. L'index/les indices de RDF 304 peuvent faciliter le mappage de données de RDF sur les données natives enregistrées dans la ou les mémoires de données de RDF. De plus, l'index/les indices de RDF 304 peuvent permettre de traverser d'une manière efficace la structure de graphe dirigé des données de RDF. Par exemple, l'index/les indices de RDF 304 peuvent fournir des références concernant des valeurs particulières d'objets pour une relation définie. Par exemple, un index de toutes les valeurs de l'objet "AuthorName" concernant des ressources par le prédicat "creator" peut être produit pour mapper les positions respectives dans la vue unifiée des données de RDF. Lorsqu'une requête est reçue vers des ressources identifiées ayant "John Smith" comme créateur, le service de base de données de RDF 301 peut accéder à l'index particulier au lieu de traverser la vue unifiée complète des données de RDF. Si "John Smith" est placé avec l'index, le service de base de données de RDF 301 peut récupérer les ressources identifiées et de quelconques objets convenables des ressources identifiées, destinés à être retournés en réponse à la requête. D'une manière similaire, l'index/les indices de RDF 304 peuvent contenir des références à des sujets de RDF qui sont associés à un prédicat de RDF particulier. La recherche des triplets de RDF conformément aux requêtes de RDF peut commencer à partir des noeuds dans la vue unifiée des données de RDF, comme identifié par l'index/les indices de RDF 304. La figure 3B est un organigramme d'un déroulement de traitement pouvant être exécuté par une base de données de RDF selon des modes de réalisation représentatifs. À l'étape 311, une transaction de base de données de RDF est reçue, par exemple, pour ajouter un triplet de RDF à la base de données de RDF. À l'étape 312, la transaction de RDF est validée vis-à-vis du ou des schémas de RDF par l'intermédiaire d'un service de référentiel de RDF. À l'étape 313, une comparaison logique est effectuée pour déterminer si la transaction de RDF est conforme au(x) schéma(s) de RDF. Si la transaction est conforme au(x) schéma(s) de RDF, le déroulement du traitement passe à l'étape 314, où la mémoire de données de RDF est remplie de nouvelles données et ce qui est possible, une mise à jour de l'index/des indices de RDF est effectuée. Si la transaction de RDF n'est pas conforme au(x) schéma(s) de RDF, le déroulement du traitement passe à l'étape 315, où une erreur convenable est indiquée. La figure 3C est un organigramme d'un déroulement de traitement pouvant être exécuté par une base de données de RDF selon des modes de réalisation représentatifs. À l'étape 321, une requête de RDF est reçue. À l'étape 322, on peut examiner dans l'index/les indices de RDF, des éléments de RDF correspondant aux paramètres de requêtes (par exemple, les sujets, prédicats et objets). À l'étape 323, la traversée du graphe dirigé unifié par les données de RDF fournies par le service de référentiel de RDF commence par les noeuds identifiés par l'index/les indices de RDF. De plus, le RDF permet de concevoir des schémas de metadata dans lesquels des relations entre des propriétés peuvent être définies en utilisant la relation "subProperty0f". Ce type de mécanisme est utilisé pour indiquer qu'une propriété a la signification d'une autre propriété plus une certaine signification supplémentaire. Par exemple, la propriété "ModifiedDate" peut étendre le concept de la propriété "Date" en utilisant ce type de relation. Lorsqu'une requête est soumise concernant des ressources ayant des metadata de propriété qui correspondent à une certaine valeur, les ressources ayant les metadata de propriété qui correspondent à la valeur et les ressources ayant des metadata de propriétés secondaires qui correspondent à la valeur peuvent être retournées sous la forme d'une collection. Il peut être possible de modifier les metadata associées aux deux types de ressources en utilisant le même mécanisme. Toutefois, ceci peut être problématique. Par exemple, un code peut être créé pour modifier des metadata de propriétés avant que la propriété secondaire soit créée. Ainsi, le code précédemment créé peut modifier de manière inappropriée les ressources avec les metadata de la propriété secondaire. La figure 4 représente un système 400 pour traiter des metadata associées à des propriétés et des propriétés secondaires. Une interface de programmation d'application de collection (API) 401 permet aux processus logiciels d'avoir accès aux collections de ressources identifiées conformément au schéma de RDF. L'API de collection 401 s'interface avec le référentiel de RDF 403 du référentiel de RDF 402. L'interface de référentiel de RDF 403 récupère les ressources appropriées à partir de la ou des mémoires de données de RDF 404 en utilisant le schéma de RDF 405. L'API de collection 401 peut recevoir des requêtes de collection et des requêtes pour modifier des metadata associées aux ressources des collections demandées. Lorsqu'une requête est reçue pour modifier les metadata d'une ou plusieurs ressources d'une collection, l'API de collection 401 peut utiliser des définitions de propriété secondaires 406 pour déterminer si la requête est convenable. La figure 5 est un organigramme du traitement des metadata associées aux propriétés et propriétés secondaires selon des modes de réalisation représentatifs. L'organigramme peut être mis en oeuvre par un système 400. L'organigramme peut également être mis en oeuvre à l'intérieur d'un service de base de données de RDF si cela est désiré. À l'étape 501, une requête de collection est reçue. À l'étape 502, la collection est retournée. À l'étape 503, une requête pour modifier une valeur de propriété des metadata de ressources d'au moins une ressource dans la collection est reçue. À l'étape 504, on effectue une détermination logique pour déterminer si la modification demandée influe sur les metadata de propriétés ou les metadata de propriétés secondaires. Si la modification influe sur les metadata de propriétés, l'organigramme de traitement passe à l'étape 505, où la modification est autorisée. Si la modification influe sur les metadata de propriétés secondaires, le déroulement du traitement passe à l'étape 506, où la modification n'est plus autorisée. En supprimant l'autorisation de la modification de metadata de propriétés secondaires par l'intermédiaire du même mécanisme que celui qui modifie les metadata de propriétés, l'intégrité des données peut être conservée. Par exemple, lorsque de nouvelles relations de propriétés secondaires sont créées, les applications logicielles antérieures qui modifient les metadata associées à la ou aux relations de propriétés ne sont pas autorisées à corrompre par inadvertance les metadata associées aux relations de propriétés secondaires. Dans des modes de réalisation représentatifs, un transcodeur de RDF permet de récupérer les metadata associées à des mémoires de données de RDF par une diversité d'applications nécessitant que les données respectives soient reçues en utilisant des types et/ou formats de données différents. Par exemple, les metadata définies conformément à un schéma donné peuvent utiliser un type entier, tandis que les metadata définies conformément à un second schéma peuvent utiliser un type de chaîne de caractères. Les metadata définies conformément à chaque schéma peuvent se référer à la même ressource physique. Ainsi, les metadata définies conformément à chaque schéma peuvent être enregistrées en utilisant un type de données natives physiques unique. Un transcodeur de RDF peut récupérer les données dans la mémoire de données dans le format natif et peut transcoder les données dans le format approprié pour les schémas respectifs. De plus, ou à titre de variante, le transcodage de RDF peut effectuer une conversion d'unités (par exemple, de dollars en yens). Le transcodeur de RDF peut permettre de fournir les données transcodées à l'application demandeuse dans le format approprié. Le transcodeur de RDF peut être mis en oeuvre sous la forme d'un service dans un environnement de serveur d'application convenable. La figure 6 représente un système 600 mettant en oeuvre une fonctionnalité de transcodage selon des modes de réalisation représentatifs. Le système 600 peut être incorporé dans un système de base de données de RDF, si cela est désiré. À titre de variante, le système 600 peut être mis en oeuvre indépendamment d'un système de base de données de RDF auquel des applications convenables doivent directement accéder. Le système 600 comporte un générateur de code d'ensemble de metadata 601. Le générateur de code d'ensemble de metadata 601 est typiquement un processus logiciel qui produit des objets d'accès de transcodage 604-1 à 604-N qui accèdent au(x) données de RDF 603. Dans des modes de réalisation représentatifs, les objets d'accès de transcodage 604-1 à 604-N permettent de récupérer et/ou de modifier les metadata enregistrées en association avec le schéma de RDF. De plus, les objets d'accès de transcodage 604-1 à 604-N peuvent fournir des méthodes (sous-programmes de codes logiciels appelés pour exécuter la récupération et/ou la modification de données) avec des signatures de types multiples. Par exemple, les objets d'accès 604-1 à 604-N permettent de retourner les données à un processus logiciel appelant en utilisant une diversité de types de données. Un processus logiciel appelant donné peut nécessiter la récupération des metadata en utilisant un format de chaîne, tandis qu'un autre processus logiciel appelant peut nécessiter la récupération des metadata en utilisant un format entier. L'un des objets d'accès 604- 1 à 604-N peut obtenir les metadata particulières à partir de la ou des mémoires de données de RDF 603. L'objet d'accès 604 peut alors transcoder les données dans le type demandé et retourner les metadata au processus logiciel appelant. Les objets d'accès 604-1 à 604-N peuvent également positionner les valeurs des metadata en utilisant des méthodes ayant des signatures de types multiples. Dans des modes de réalisation représentatifs, la fonctionnalité de transcodage est automatiquement mise en oeuvre par un générateur de code d'ensemble de metadata 601. De façon spécifique, le schéma de RDF 602 peut inclure des informations de transcodage de type 605 pour associer des relations, des classes, des propriétés et/ou analogue, à des types de données multiples pour se référer aux mêmes metadata physiques enregistrées dans les mémoires de données de RDF 603. Le générateur de code d'ensemble de metadata 601 peut analyser un schéma de RDF 603 pour identifier des relations multiples définies de cette manière. En réponse à cela, le générateur de code d'ensemble de metadata 601 peut créer un objet d'accès de transcodage respectif 604 pour permettre l'accès aux metadata en fonction des différents types de données des relations définies disparates. Une fois mis en oeuvre par l'intermédiaire d'instructions exécutables, divers éléments de modes de réalisation représentatifs sont essentiellement le code définissant les opérations de ces divers éléments. Les instructions ou le code exécutable peuvent être obtenus à partir d'un support lisible (par exemple, un support à disque dur, un support optique, une EPROM, une EEPROM, un support à bande, un support à cartouche, et/ou analogue) ou communiqués par l'intermédiaire d'un signal de données provenant d'un support de communication (par exemple, l'Internet). En fait, un support lisible peut inclure un support quelconque pouvant enregistrer ou transférer des informations. La figure 7 illustre un système informatique 700 adapté conformément à des modes de réalisation représentatifs. L'unité centrale de traitement (CPU) 701 est couplée à un bus de système 702. Le CPU 701 peut être un CPU à usage général quelconque. Toutefois, les modes de réalisation ne sont pas limités par l'architecture du CPU 701, dans la mesure où le CPU 701 supporte les opérations comme ici décrites. Le système informatique 700 comporte également une mémoire à accès aléatoire (RAM) 703, pouvant être une SRAM, une DRAM, une SDRAM ou analogue. Le système informatique 700 comporte une ROM pouvant être une PROM, une EPROM, une EEPROM ou analogue. La RAM 703 et la ROM 704 contiennent des données et des programmes de l'utilisateur et du système comme cela est bien connu dans la technique. Le système informatique 700 comporte également un adaptateur d'entrée/sortie (I/O) 705, un adaptateur de communication 711, un adaptateur d'interface utilisateur 708 et un adaptateur d'affichage 709. L'adaptateur d'I/O 705 est connecté à des dispositifs de mémorisation 706 tels qu'un ou plusieurs parmi un disque dur, un lecteur de CD, un lecteur de disquettes, un dérouleur de bande, vers le système informatique 700. L'adaptateur de communication 711 est adapté à coupler le système informatique 700 à un réseau 712, qui peut être un ou plusieurs parmi un réseau téléphonique, un réseau local (LAN) et/ou étendu (WAN), un réseau Ethernet, et/ou le réseau Internet. L'adaptateur d'interface utilisateur 708 couple des dispositifs d'entrée d'utilisateur, tels qu'un clavier 713 et un dispositif de pointage 707, au système informatique 700. L'adaptateur d'affichage 709 est commandé par un CPU 701 pour contrôler l'affichage sur le dispositif d'affichage 710. De plus, des modes de réalisation représentatifs peuvent enregistrer le code exécutable mettant en oeuvre la fonctionnalité de traitement de RDF présentée ci-dessus. Par exemple, le code exécutable définissant les opérations du service de base de données de RDF 721, du service de référentiel de RDF 723, du générateur de code de metadata 725 et/ou analogue, peut être mémorisé sur un support convenable accessible par un ou plusieurs des dispositifs de mémorisation 706. De même, un ou des schémas de RDF 722 et une ou des mémoires de données de RDF 724 peuvent être enregistrés sur un support convenable accessible par l'un des dispositifs de mémorisation 706. Les modes de réalisation représentatifs peuvent procurer un certain nombre d'avantages. Par exemple, les modes de réalisation représentatifs peuvent optimiser le traitement des transactions de la base de données de RDF en adaptant la structure d'une base de données de RDF. Les modes de réalisation représentatifs peuvent utiliser des indices de base de données qui correspondent au graphe dirigé défini par les données de RDF. Les modes de réalisation représentatifs peuvent maintenir, en outre, l'intégrité d'une base de données de RDF en mettant en oeuvre les contraintes du schéma de RDF sous la forme d'une condition d'introduction de nouvelles données dans une base de données de RDF. Les modes de réalisation représentatifs peuvent, en outre, empêcher la corruption de données de s'effectuer en séparant les transactions conformément à des relations de propriétés et de propriétés secondaires. Les modes de réalisation représentatifs peuvent, en outre, optimiser la mémorisation des données de RDF dans des mémoires de données en utilisant les mêmes structures de données natives auxquelles il doit être accédé conformément aux signatures de types de données multiples définies par des schémas multiples. TRADUCTION DES FIGURES FIGURE 3A 301 SERVICE DE BASE DE DONNÉES DE RDF 302 SERVICE DE RÉFÉRENTIEL DE RDF 303 MÉMOIRE(S) DE DONNÉES DE RDF 304 INDEX/INDICES DE RDF 305 SCHÉMA(S) DE RDF FIGURE 3B 311 RÉCEPTION DE TRANSACTION DE BASE DE DONNÉES DE RDF 312 VALIDATION VIS-À-VIS DU OU DES SCHÉMAS DE RDF PAR L'INTERMÉDIAIRE D'UN SERVICE DE RÉFÉRENTIEL DE RDF 313 TRANSACTION DE RDF CONFORME AU(X) SCHÉMA(S) DE RDF ? OUI NON 314 REMPLISSAGE DE LA MÉMOIRE DE DONNÉES DE RDF AVEC DE NOUVELLES DONNÉES ET MISE À JOUR DE L'INDEX/DES INDICES DE RDF 315 INDICATION D'ERREUR FIGURE 3C 321 RÉCEPTION REQUÊTE DE RDF 322 EXAMEN DANS L'INDEX/LES INDICES DE RDF, DES ÉLÉMENTS DE RDF CORRESPONDANTS (SUJETS, PRÉDICATS, OBJETS) 323 DÉBUT TRAVERSÉE DU GRAPHE DIRIGÉ UNIFIÉ PAR LES DONNÉES DE RDF AUX NOEUDS IDENTIFIÉS PAR L'INDEX/LES INDICES DE RDF FIGURE 4 401 COLLECTIONS API 403 INTERFACE DE RÉFÉRENTIEL DE RDF 709 ADAPTATEUR D'AFFICHAGE REVENDICATIONS 1. Système pour traiter des données de cadre de description de ressources (RDF), comprenant : une pluralité de schémas de RDF (305) définissant des éléments de RDF et des relations entre certains desdits éléments de RDF ; une mémoire de données de RDF (303) pour mémoriser des triplets de RDF en conformité avec ladite pluralité de schémas de RDF ; un service de base de données de RDF (301) pour recevoir les transactions de la base de données pour ajouter des triplets de RDF à ladite mémoire de données de RDF, dans lequel le service de base de données de RDF peut être actionné pour valider un triplet de RDF par rapport à ladite pluralité de schémas de RDF avant d'introduire le triplet de RDF dans la mémoire de données de RDF. 2. Système selon la revendication 1, comprenant en outre : un service de référentiel de RDF (302) fournissant une vue unifiée d'un graphe dirigé défini par ladite pluralité de schémas de RDF, dans lequel ledit service de base de données de RDF peut être actionné pour traverser ledit graphe dirigé lors de la validation d'un triplet de RDF destiné à être ajouté à ladite mémoire de données de RDF. 3. Système selon la revendication 1, comprenant en outre : un index de RDF (304) contenant des références à des sujets de RDF qui sont associés à un prédicat de RDF particulier ; et un service de référentiel de RDF (302) fournissant une vue unifiée d'un graphe dirigé desdits triplets de RDF dans ladite mémoire de données de RDF, dans lequel ledit service de base de données de RDF reçoit des requêtes d'éléments de RDF ayant une relation définie par un prédicat de requête, dans lequel ledit service de base de données de RDF utilise ledit index de RDF pour commencer la traversée dudit graphe dirigé depuis les sujets de RDF associés audit prédicat de requête. 4. Système selon la revendication 1, dans lequel ledit service de base de données de RDF reçoit une requête associée à une relation définie par un prédicat de requête, ledit service de base de données de RDF fournit une collection de données associées à des triplets de RDF comportant ledit prédicat de requête et des données associées à des triplets de RDF comportant un prédicat associé audit prédicat de requête par une relation de propriété secondaire ; dans lequel, lorsque ledit service de base de données de RDF reçoit une transaction de base de données pour modifier des objets de ladite collection associés à des sujets par ledit prédicat de requête, ledit service de base de données de RDF ne modifie pas les objets ayant un prédicat qui est associé audit prédicat de requête par une relation de propriété secondaire. 5. Système selon la revendication 1, dans lequel un schéma de ladite pluralité de schémas définit un premier élément de RDF selon un premier type de données et un autre schéma de ladite pluralité de schémas définit un second élément de RDF selon un second type de données, chaque instance dudit premier élément de RDF possède une instance correspondante dudit second élément de RDF, chaque instance dudit premier élément de RDF et son instance correspondante dudit second élément de RDF sont enregistrées sous la forme d'une structure de données natives uniques dans ladite mémoire de données de RDF ; et dans lequel ledit système comprend en outre : un processus transcodeur pour convertir ladite structure de données natives unique en au moins un parmi ledit premier type de données et ledit second type de données. 6. Procédé pour traiter des données de cadre de description de ressources (RDF), comprenant : la réception d'une transaction de base de données de RDF pour remplir une base de données de RDF avec un triplet de RDF (311) ; la traversée d'un graphe dirigé unifié d'une pluralité de schémas de RDF pour déterminer si ledit triplet de RDF est conforme aux relations définies par ladite pluralité de schéma de RDF (312) ; et l'ajout dudit triplet de RDF à une mémoire de données de RDF lorsque ladite traversée détermine que ledit triplet de RDF est conforme aux relations définies par ladite pluralité de schémas de RDF (314). 7. Procédé selon la revendication 6, comprenant en outre : la mise à jour d'un index de RDF conformément audit triplet de RDF ajouté, dans lequel ledit index de RDF contient des références à des objets de RDF qui sont associés à un prédicat de RDF particulier. 8. Procédé selon la revendication 7, comprenant en outre : la réception de la requête d'éléments de RDF dans une base de données de RDF ayant une relation définie par un prédicat de requête sur un objet ayant une valeur de requête (321) ; la recherche dudit index de RDF pour identifier des objets de RDF correspondant à ladite valeur de requête (322) ; et la traversée d'une vue unifiée d'un graphe dirigé défini par des triplets de RDF dans ladite mémoire de données en fonction de ladite recherche dudit index de RDF (323). 9. Procédé selon la revendication 6, comprenant en outre : la réception d'une requête de base de données pour identifier des éléments de RDF conformément à un prédicat de requête (501) ; le retour d'une collection d'éléments de RDF qui comporte des données de RDF associées audit prédicat de requête et des données de RDF associées à un prédicat qui concerne ledit prédicat de requête par une relation de propriété secondaire (502) ; la réception d'une transaction de base de données pour modifier les objets de ladite collection associés aux sujets par ledit prédicat de requête (503) ; et la modification des seuls objets associés à des sujets par ledit prédicat de requête et l'abandon des objets associés à un prédicat associé audit prédicat de requête par une relation de propriété secondaire non modifiée (505, 506). 10. Procédé selon la revendication 6, dans lequel un schéma de ladite pluralité de schémas définit un premier élément de RDF conformément à un premier type de données et un autre schéma de ladite pluralité de schémas définit un second élément de RDF conformément à un second type de données, chaque instance dudit premier élément de RDF possède une instance correspondante dudit second élément de RDF, chaque instance dudit premier élément de RDF et son instance correspondante dudit second élément de RDF sont enregistrées dans une structure de données native unique dans ladite mémoire de données de RDF, dans lequel ledit procédé comprend en outre : le transcodage de ladite structure de données natives unique dans au moins un type parmi ledit premier type de données et ledit second type de données lors de l'accès d'une instance d'un élément parmi ledit premier élément de RDF et son second élément de RDF correspondant.