FR 2853972 A1 20041022 FR 0404052 A 20040416 CONTEXTE Un cadre de description de ressources (RDF), tel que défini par le World Wide Web Consortium (W3C), peut être un modèle pour stocker des informations. Plus 5 particulièrement, le modèle de RDF peut être conçu pour stocker des informations concernant des informations, des METADATA. Dans le modèle RDF, les METADATA sont regroupées en utilisant un triplet logique. Dans sa forme la plus simple, le triplet peut comprendre un 10 sujet, un prédicat et un objet. Par exemple, l'énoncé "Leslie a 34 ans" peut être divisé en le triplet: sujet = Leslie, prédicat = âge, et objet = "34". Ainsi, le prédicat qui relie le sujet "Leslie" à l'objet "34" peut être la propriété 'âge'. En jargon plus technique, le 15 triplet du modèle de RDF peut être défini par une ressource (sujet), une propriété (prédicat) et un objet. Bien que dans l'exemple simple fourni ci-dessus, la ressource était "Leslie", dans le modèle de RDF, une ressource peut être un élément quelconque auquel on peut 20 affecter un Universal Resource Identifier (Identifiant Universel de Ressources) (URI). Un exemple de la ressource à laquelle on peut affecter un URI est un document posté sur le World Wide Web. Un document avec un URI peut être aussi simple qu'une image numérique, ou 25 peut être aussi complexe qu'une série de commandes lues par un navigateur Web pour créer une page Web consultable. Le modèle de RDF peut ne pas définir des propriétés ou prédicats; en remplacement, le modèle de 30 RDF peut définir uniquement la relation du stockage de METADATA sous la forme d'un triplet. Ainsi, la population générale peut être libre de définir une série quelconque de propriétés pouvant être appropriées pour ce genre de sujets particulier. Chacun de ces ensembles 35 de propriétés définies peut être appelé schéma, schéma de RDF ou "espace de nom". Bien que la population générale puisse être libre de définir des schémas de RDF, il existe des schémas définis précédemment et disponibles publiquement pour des ressources particulières. Par exemple, une 5 organisation a créé le schéma de METADATA "Dublin Core", orienté vers les propriétés de document Internet, tels que des documents Web consultables avec un navigateur Web, des images postées sur le Web, et analogue. Le schéma de "Dublin Core" peut définir quinze propriétés, 10 telles que le titre, l'auteur, le diffuseur, un autre agent (tel que des éditeurs, transcripteurs ou illustrateurs ayant effectué une contribution intellectuelle significative), la date, le type d'objet et analogue. Toutefois, d'autres schémas peuvent être 15 créés, dans lesquels des propriétés, bien qu'étant apparemment les mêmes, ont des significations différentes. Ainsi, par exemple, selon le schéma de "Dublin Core", 'Date' peut avoir une signification particulière, à savoir, la date de publication. Dans 20 d'autres schémas, 'Date' peut être définie selon d'autres manières, par exemple la date de création de l'oeuvre. Le modèle de RDF, ainsi que les divers schémas qui ont été produits ou peuvent être produits, peuvent 25 ne pas être un langage de programmation. En remplacement, les informations de MEDATA peuvent être codées en "extensible Markup Language" (XML). Les programmeurs peuvent accéder aux informations codées en XML par codage manuel de programmes dans divers autres 30 langages de programmation, tels que Java, C++, C# (C sharp) et analogue. Toutefois, pour accéder aux METADATA à partir d'une base de données codée en utilisant le modèle de RDF, il peut être nécessaire à un programmeur de connaître le schéma ou les schémas pouvant être 35 utilisés dans la base de données créée sous le modèle de RDF. Ainsi, avant qu'un programmeur ne puisse accéder à des METADATA en format RDF, un temps significatif peut être requis pour vérifier le schéma ou les schémas utilisés et pour coder des programmes pour accéder à ces informations. BREF RÉSUMÉ DE CERTAINS DES MODES DE RÉALISATION DE L'INVENTION La spécification peut décrire un procédé comprenant la lecture d'une source d'entrée à base de 10 RDF par un compilateur, et la génération d'un ensemble de mises en oeuvre par le compilateur, basées sur la source d'entrée à base de RDF. La spécification peut également décrire un support lisible par un ordinateur comprenant un 15 programme exécutable, qui, lorsqu'il est exécuté, met en oeuvre un procédé tel que la lecture d'une source d'entrée basée sur un Cadre de Description de Ressources (RDF), la génération d'une liste de sous-programmes basée sur les propriétés de la source d'entrée au niveau 20 RDF, et la génération d'un ensemble de sous- programmes basée sur les propriétés de la source d'entrée s'appuyant sur le RDF. BRÈVE DESCRIPTION DES DESSINS 25 Pour une description détaillée de modes de réalisation représentatifs, il va maintenant être fait référence aux dessins annexés, dans lesquels: la figure l est un schéma par blocs d'une mise en oeuvre de modes de réalisation représentatifs. 30 NOTATION ET NOMENCLATURE Certains termes sont utilisés dans l'ensemble de la description et des revendications qui suivent pour se référer à des composants de systèmes particuliers. 35 Comme le comprendra un homme de l'art, les entreprises d'informatique peuvent se référer à un composant par des noms différents. Ce document n'a pas pour but de faire la distinction entre des composants dont les noms diffèrent, mais pas la fonction. Dans l'explication et dans les revendications qui suivent, les termes 5 "comportant" et "comprenant" sont utilisés d'une façon ouverte et ainsi, doivent être interprétés comme signifiant "comportant, mais sans y être limité...". DESCRIPTION DÉTAILLÉE La description suivante est orientée vers divers modes de réalisation de l'invention. Bien qu'un ou plusieurs de ces modes de réalisation puissent être préférés, les modes de réalisation décrits ne doivent pas être interprétés ou par ailleurs utilisés comme 15 limitant la portée de la description, y compris des revendications, sauf spécification contraire. De plus, un homme de l'art comprendra que la description qui suit a une application large et l'explication d'un mode de réalisation quelconque n'est destinée qu'à être un 20 exemple de ce mode de réalisation et n'est pas destinée à suggérer que la portée de la description, y compris les revendications, est limitée à ce mode de réalisation. Comme mentionné dans le paragraphe de 25 contexte, il peut déjà y avoir plusieurs schémas définis, tels que le schéma de "Dublin Core" (DC). Le schéma de DC peut définir quinze propriétés associées à des METADATA, concernant des documents Web. Le tableau suivant peut donner la liste des quinze propriétés 30 telles que le schéma de DC a défini à un instant particulier. Propriété Description Nom donné à la ressource, habituellement Titre par le créateur ou l'éditeur. Personne ou organisation principalement responsable de la création du contenu intellectuel de la ressource. Par Auteur ou créateur exemple, les auteurs dans le cas des documents écrits, les artistes, les photographes ou les illustrateurs dans le cas de ressources visuelles. Sujet de la ressource. Le sujet est Sujet et mots- typiquement exprimé par des mots-clés ou clés des phrases qui décrivent le sujet ou le contenu de la ressource. Description textuelle du contenu de la ressource, comportant des abrégés dans Description le cas d'objets tels que des documents ou des descriptions de contenus dans le cas de ressources visuelles. Entité responsable de la réalisation de la ressource disponible sous sa forme Diffuseur actuelle, par exemple une société de diffusion, un département universitaire, ou une entité d'entreprise. Personne ou organisation non spécifiée dans un élément de créateur ayant réalisé des contributions intellectuelles significatives à la Autre ressource, mais dont la contribution et contributeur secondaire pour une quelconque personne ou organisation spécifiée dans un élément de créateur (par exemple, éditeur, transcripteur et illustrateur). Date associée à la création ou à la mise Date à disposition de la ressource. Comporte (entre autres) des dates sous les formes YYYY et YYYY-MM-DD. Catégorie de la ressource, telle qu'une page personnelle, une nouvelle, un poème, un document de travail, un Type de compte-rendu technique, un essai, un ressource dictionnaire. Pour l'interopérabilité, le type doit être choisi à partir d'une liste énumérée qui est en cours de mise au point dans la série de l'atelier. Format de données et, de façon optionnelle, dimensions (par exemple, taille, durée) de la ressource. Le Format format est utilisé pour identifier le logiciel et ce qui est possible, les circuits pouvant être nécessaires pour afficher ou utiliser la ressource. Chaîne ou nombre utilisé pour identifier la ressource de manière unique. Des exemples pour des ressources en réseau comportent des URL et URN (lorsqu'elles Identifiant de sont mises en oeuvre). D'autres ressource identifiants globalement spécifiques, tels que les numéros des livres de la norme internationale (ISBN) ou d'autres noms de format sont également des candidats pour cet élément. Informations concernant une seconde Source ressource dont est déduite la présente ressource. Langue Langue du contenu intellectuel de la ressource Identifiant d'une seconde ressource et de sa relation avec la présente Relation ressource. Cet élément est utilisé pour exprimer des liens entre des ressources associées. Caractéristiques spatiales et/ou temporelles du contenu intellectuel de la ressource. L'étendue spatiale se réfère à une région physique (par exemple, un secteur céleste) utilisant des noms d'emplacements ou des coordonnées (par exemple, la longitude et la latitude). L'étendue temporelle se Étendue réfère au sujet de la ressource plutôt qu'au moment o elle a été créée ou rendue disponible (cette dernière appartenant à l'élément de date). L'étendue temporelle est typiquement spécifiée en utilisant des périodes de temps nommées (par exemple, le néolithique) ou le même format de date/temps. Instructions de gestion des droits, identifiant lié à une instruction de Gestion des gestion des droits ou identifiant lié à droits un service fournissant des informations concernant la gestion des droits pour la ressource. TABLEAU 1 Comme on peut le voir d'après l'exemple précédent de tableau du schéma de DC, le schéma de DC 5 peut définir certaines propriétés et dans certains cas, le format de ces propriétés. D'autres schémas peuvent définir des propriétés avec des noms analogues, et cependant des descriptions ou formes différentes. La propriété du schéma de DC, 'Date', peut être définie 10 comme ayant la forme "YYYY-MM-DD"; toutefois, des langages de programmation tels que Java, C++, C# et analogue, peuvent définir 'Date' sous une forme différente, ou dans un ordre différent. Dans un langage de programmation, une forme prédéfinie pour la propriété 'Date' peut être une chaîne. Dans encore un autre langage, la propriété 'Date' peut être une série de 5 valeurs entières, et ayant un ordre comprenant un mois de tête, suivie par un jour, puis par une année. Dans la conception des programmes (en utilisant des langages de programmation tels que Java, C++, C#, et analogue), pour accéder à des METADATA dans un système de stockage à 10 base de RDF, il peut être nécessaire de s'assurer que les types de données revenant de l'accès sont d'un type sûr. 'Type sûr' peut signifier qu'en effectuant l'accès à la base de données de METADATA, les types de données peuvent être convertis pour correspondre au type défini 15 dans le langage cible. Les modes de réalisation de l'invention, présentés plus complètement ci-dessous, traitent des problèmes possibles concernant des API de type sûr. Il peut y avoir un grand nombre de schémas 20 prédéfinis et disponibles publiquement, le DC n'étant qu'un exemple. Chacun de ces schémas peut définir un grand nombre de propriétés pour le type particulier de ressources pour lequel le schéma a été créé. Chacun des types de propriétés peut conduire à un sous-programme 25 d'accès. Par exemple, le schéma de DC illustré ci-dessus peut donner naissance à quinze sousprogrammes distincts pour lire des METADATA dans une base de données à base de RDF en utilisant le schéma de DC. Deux exemples peuvent être un programme "get.date" et un programme 30 "get.author". Toutefois, la création manuelle de ces exemples de programmes peut consommer un temps excessif pour un programmeur ayant besoin de n'accéder qu'à une seule ou à quelques informations. Les modes de réalisation de la présente 35 invention peuvent produire des sous-programmes pour un accès de type sûr à des bases de données codées en utilisant le modèle de RDF, des bases de données au niveau RDF, pour un langage quelconque parmi une diversité de langages de programmation, tels que, mais sans limitation, Java, C++, C# et analogue. Plus 5 particulièrement, des modes de réalisation de l'invention peuvent prendre la forme d'un compilateur pouvant accéder à un schéma de RDF, et peuvent produire une interface de programme d'application en langage natif (API) et une série de mises en oeuvre de type sûr 10 en langage natif, en se basant sur les propriétés définies dans le schéma. Les mises en oeuvre peuvent, de même, être appelées programmes, sous-programmes et/ou liens. La figure 1 illustre, sous forme de schéma par blocs, des modes de réalisation représentatifs. En 15 particulier, les modes de réalisation représentatifs peuvent comprendre un compilateur 10. Le compilateur 10 peut être un programme exécutable, programmé dans un quelconque langage de programmation disponible. Le compilateur 10 peut être conçu et codé de façon qu'il 20 prenne comme données d'entrée un schéma de RDF 12. Le schéma de RDF peut être un schéma prédéfini et publiquement disponible, tel que le schéma de DC, ou peut être un schéma défini par un particulier ou une organisation pour un but interne particulier. Quel que 25 soit le schéma de la source, le compilateur 10 peut lire le schéma 12, peut produire une interface 14 à partir des propriétés définies et peut également produire un ensemble de mises en oeuvre en langage natif 16. Dans des modes de réalisation de l'invention, 30 l'interface 14 peut être une liste de mises en oeuvre disponibles telles que produites pour le schéma particulier analysé par le compilateur 10. Le nombre d'API disponibles listées dans une interface telle que l'interface 14 peut être associé au nombre de propriétés 35 définies dans le schéma et au nombre d'opérations exécutées. Dans des modes de réalisation de la présente invention, il peut y avoir quatre sous-programmes pour chaque propriété définie dans le schéma. À des fins d'explication, on considère une propriété de schéma générique marquée ici "Property". Cette propriété 5 générique peut ainsi donner naissance aux mises en oeuvre dont on peut donner un exemple de nomenclature dans le tableau 2. Sous-programme But Void addProperty Peut s'ajouter.à la fin de la (type value) collection de valeurs de propriétés. Peut obtenir toutes les valeurs de Collection propriétés et de propriétés getProperty () secondaires telles que définies par le schéma de RDF. Peut fixer la propriété de la ressource (remplacer la valeur Void setProperty existante, s'il y a lieu). Si la (type value) ressource a plus d'une propriété du type Property, peut retourner une erreur. Type Peut retourner la première valeur getFirstProperty d'une propriété, ou null, si aucune () n'existe. TABLEAU 2 Le compilateur 10 des divers modes de réalisation peut également produire des mises en oeuvre en langage natif 16. Les "mises en oeuvre en langage natif" peuvent signifier qu'un compilateur 10, selon au 15 moins certains modes de réalisation de l'invention, peut ne pas produire de logiciel exécutable; en remplacement, le compilateur 10 peut produire des mises en oeuvre dans leur langage natif. Par exemple, si le compilateur 10 est conçu pour vérifier un schéma de RDF 20 12 et produire des API Java basées sur les propriétés définies, alors dans au moins certains modes de réalisation de l'invention, le compilateur peut produire non seulement l'interface 14, mais peut également produire les mises en oeuvre en langage Java, mises en 5 oeuvre en langage natif. De cette manière, les mises en oeuvre ne dépendent pas du matériel. Un utilisateur peut ensuite compiler les mises en oeuvre en langage natif en utilisant un compilateur matériel spécifique. Toutefois, dans d'autres modes de réalisation de l'invention, le 10 compilateur 10 peut produire un code exécutable spécifique au matériel. Les mises en oeuvre 16 produites par le compilateur 10 peuvent être conçues pour être exécutées (une fois compilées), lire et/ou modifier des METADATA à l'intérieur d'une base de données s'appuyant 15 sur le RDF, et retourner des valeurs (si nécessaire pour la fonction exécutée) . Dans des modes de réalisation de l'invention, ce sont les mises en oeuvre 16 qui exécutent les conversions de types nécessaires quelconques pour s'assurer que les données retournées 20 par les sous-programmes sont de type sûr. Il existe un grand nombre de langages natifs possibles dans lesquels le compilateur peut créer l'API 14 et la mise en oeuvre 16 pour un schéma de RDF spécifique 12. Par exemple, et sans limitation, les 25 langages peuvent comprendre Java, C++, C# et des langages similaires existant actuellement, ainsi que des langages de programmation restant encore à mettre au point. L'explication ci-dessus est destinée à 30 illustrer les principes et divers modes de réalisation de la présente invention. Un grand nombre de variantes et de modifications apparaîtront aux hommes de l'art après compréhension complète de la description cidessus. Par exemple, le compilateur 10 des modes de 35 réalisation de l'invention peut prendre comme entrée un schéma de RDF 12; toutefois, d'autres modes de réalisation peuvent lire des METADATA s'appuyant sur le RDF, plutôt qu'un aménagement sous-jacent, pour pressentir une API et des mises en oeuvre en langage natif. Dans les modes de réalisation o des METADATA 5 s'appuyant sur le RDF sont utilisées comme entrée vers le compilateur 10, on notera que l'API 14 et les mises en oeuvre en langage natif correspondantes peuvent ne pas lister et contenir respectivement une mise en oeuvre pour chaque propriété du schéma utilisé dans l'ensemble 10 de METADATA identifiées dans les METADATA s'appuyant sur le RDF, mais en remplacement, ce qui est possible, seules celles qui sont utilisées dans les METADATA codées basées sur le modèle de RDF. En outre, il n'est pas nécessaire de limiter le compilateur 10 à produire 15 des mises en oeuvre en langage natif pour un seul langage; en remplacement, un programme compilateur unique, tel que le compilateur 10, peut être programmé pour produire les mises en oeuvre en langage natif pour un langage quelconque parmi une diversité de langages de 20 programmation. Il est voulu que les revendications suivantes soient interprétées comme englobant toutes ces variantes et modifications. REVENDICATIONS 1. Procédé comprenant: la lecture d'une source d'entrée (12) basée sur un 5 cadre de description de ressources (RDF), par un compilateur (10) ; et la génération d'un ensemble de mises en oeuvre (16) par le compilateur, basée sur la source d'entrée à base de RDF (12). 2. Procédé selon la revendication 1, comprenant, en outre, la génération d'une interface (14) par le compilateur. 3. Procédé selon la revendication 1, dans lequel la génération d'un ensemble de mises en oeuvre (16) par le 15 compilateur comprend, en outre, la génération d'un ensemble de mises en oeuvre en langage natif Java par le compilateur (10). 4. Procédé selon la revendication 1, dans lequel la génération des mises en oeuvre (16) par le compilateur 20 (10) comprend, en outre, la génération d'un ensemble de mises en oeuvre en langage natif C++ par le compilateur (10). 5. Procédé selon la revendication 1, dans lequel la génération des mises en oeuvre (16) par le compilateur 25 (10) comprend, en outre, la génération d'un ensemble de mises en oeuvre en langage natif C# par le compilateur (10). 6. Support lisible par un ordinateur comprenant un programme exécutable, le programme exécutable étant 30 capable d'exécuter des tâches lorsqu'il est exécuté, comprenant: la lecture d'une source d'entrée basée sur un cadre de description de ressources (RDF) (12) ; la génération d'une liste de sous-programmes (14) 35 basés sur les propriétés de la source d'entrée s'appuyant sur le RDF; et la génération d'un ensemble de sous-programmes (16) basés sur les propriétés de la source d'entrée à base de RDF. 7. Support lisible par un ordinateur selon la 5 revendication 6, dans lequel la tâche de lecture de la source d'entrée à base de RDF du programme exécutable comprend, en outre, la lecture d'un ensemble de METADATA codées, basée sur un modèle de RDF. 8. Support lisible par un ordinateur selon la 10 revendication 6, dans lequel la génération d'un ensemble de sous-programmes (16) basé sur les propriétés de la source d'entrée à base de RDF comprend, en outre, la génération d'un ensemble de sous-programmes en langage natif Java. 9. Support lisible par un ordinateur selon la revendication 6, dans lequel la génération d'un ensemble de sous-programmes (16) basé sur les propriétés de la source d'entrée à base de RDF comprend, en outre, la génération d'un ensemble de sous-programmes en langage 20 natif C++. 10. Support lisible par un ordinateur selon la revendication 6, dans lequel la génération d'un ensemble de sous-programmes (16) basé sur les propriétés de la source d'entrée à base de RDF comprend, en outre, la 25 génération d'un ensemble de sous-programmes en langage natif C#.