Prise en charge du format RDF par le kit de démarrage OGDI
Une version 2.0a du kit de démarrage/accélérateur OGDI (Open Gouvernment Data) vient d’être mise en ligne sur le Centre de téléchargement Microsoft. Cette version introduit un ensemble d’évolutions vis-à-vis de la prise en charge du format RDF (Resource Description Framework) du W3C.
RDF constitue le langage de base du Web sémantique tel que décrit par le W3C. Pour un premier aperçu de RDF, au-delà du document RDF Primer du W3C, vous pouvez consulter par exemple le tutoriel Sémantique RDF disponible sur le site Developpez.com.
La suite de ce billet s’intéresse aux évolutions apportées sur les composants du kit de démarrage OGDI.
Support de la recommandation RDF par le service de données RESTful OData
Avec cette nouvelle version, le service de données RESTful OData interopérable, qui permet d’exposer les données aux formats XML, JSON et KML et donc de bénéficier directement du très large écosystème OData en termes de consommateurs et de bibliothèques et kits de développement, prend désormais également en charge le format RDF du W3C et permet ainsi de retourner les données et leurs métadonnées associées de façon formelle.
Pour retourner les données au format RDF depuis le service de données OGDI, il suffit d’ajouter format=rdf à votre requête.
Pour illustrer cette fonctionnalité, nous avons republié sous une instance OGDI fondée sur cette version 2.0a, la liste des musées de France (mise à disposition sous le format de fichier ouvert XLS sur le nouveau portail data.gouv.fr sous la Licence Ouverte de la mission Etalab).
Sur cette base, la requête suivante retourne l’ensemble de ces lieux garants de la Culture Française au format RDF :
https://ogdifrancerdf.cloudapp.net/v1/data/museesfrance?format=rdf
Le flux en retour est naturellement validé par le service de validation RDF mise à disposition par le W3C.
Evolution de l’utilitaire de chargement de données OGDI
Cette version 2.0a propose, vis-à-vis de la prise en charge du format RDF, des évolutions au niveau de l’utilitaire de chargement de données OGDI qui permet, pour mémoire, de créer, publier et mettre à jour vos données de façon autonome au niveau de votre instance de stockage Windows Azure.
L’utilitaire de chargement de données propose un onglet Dataset Columns Metadata qui permet de définir les métadonnées RDF pour les colonnes du jeu de données à charger.
Dans cet onglet, deux approches s’offrent à vous pour associer des métadonnées RDF aux colonnes :
- Vous pouvez choisir une option de ce que représente la colonne ;
- Vous pouvez éditer manuellement, pour chaque colonne, la description et l’espace de noms de la description.
Pour ce qui est de la première approche, Le champ « What it represents? » est une liste déroulante qui vous permet de choisir depuis celle-ci un attribut décrivant au mieux la colonne.
La liste des attributs disponibles peut être éditée manuellement depuis le fichier de configuration RDFNamespaces.xml. Ce dernier doit se trouver dans le même dossier que l’exécutable de l’utilitaire de chargement de données.
Plusieurs attributs peuvent être ajoutés à ce champ simplement en ajoutant le nom de l'option (property), celui de l'espace de noms (prefix) et enfin l'URL de l'espace de noms (url).
Une structure typique du fichier RDFNamespaces.xml est la suivante :
<?xml version="1.0" encoding="utf-8" ?>
<metadata>
<description>It represents the {0} of a/an {1}.</description>
<namespaces>
<namespace>
<property>Name</property>
<prefix>foaf</prefix>
<url>https://xmlns.com/foaf/0.1/</url>
</namespace>
<namespace>
<property>Address</property>
<prefix>foaf</prefix>
<url>https://xmlns.com/foaf/0.1/</url>
</namespace>
</namespaces>
</metadata>
L’élément « description » est un champ obligatoire et représente la description par défaut qui sera associée aux métadonnées. Sa valeur peut être changée, mais les deux paramètres {0} et {1} doivent être impérativement utilisés et renseignés :
- Le paramètre {0} représente le nom de la colonne ;
- Le paramètre {1} représente le nom du jeu de données.
Les éléments relatifs aux espaces de noms sont les nouveaux attributs qui peuvent être modifiés ou ajoutés pour remplir le champ « What it represents? ». Ainsi, pour ajouter un nouvel attribut, vous devez ajouter la structure suivante après le dernier nœud :
<namespace>
<property>[name of the attribute]</property>
<prefix>[name of the namespace (no spaces)]</prefix>
<url>[namespace URL]</url>
</namespace>
S’il n’y a pas d’attribut choisi dans la liste déroulante, alors les champs « Description » et « Namespace » doivent être renseignés afin de générer correctement les métadonnées. Ceci correspond à la seconde approche.
Dans la pratique, le champ « Description » est automatiquement rempli avec la phrase par défaut configurée dans le fichier RDFNamespaces.xml précédent et représente la métadonnée associée à chaque colonne.
Le champ « Namespace « définit l’espace de noms de la métadonnée associée à la colonne. Cet espace de noms doit respecter la syntaxe [prefix]=”[URL namespace]” ou [prefix]=[URL namespace].
Lorsque le jeu de données est chargé, un nouveau champ rdfsnippet est créé dans la table qui contient l’information RDF associée à l’entité en question.
Une table TableColumnsMetadata supplémentaire est aussi créée pour stockée l’information précisée dans l’onglet Dataset Columns Metadata.
Utilitaire de mise à jour des jeux de données précédemment publiés
Avec cette nouvelle version 2.0a est également fourni un utilitaire supplémentaire pour RDF appelé GenerateColumnMetadata qui permet de mettre à jour les jeux de données déjà présents dans les tables de stockage Windows Azure.
Cet utilitaire dispose pour cela d’un fichier de configuration App.config qui doit être configuré avec l’information de votre compte de stockage. Par ailleurs, le paramètre Default Description présent dans ce fichier de configuration constitue un champ obligatoire qui représente la description par défaut qui sera associée avec les métadonnées des colonnes. Sa valeur par défaut est la suivante : « It represents the {0} of a/an {1} ». Celle-ci peut être changée, mais les deux paramètres {0} et {1} sont obligatoires :
- Le paramètre {0} représente le nom de la colonne ;
- Le paramètre {1} le nom du jeu de données.
Lorsque ce module est exécuté, un fichier journal est généré dans le même dossier que le fichier exécutable. Ce journal enregistre toutes les erreurs et les mises à jour avec succès vis-à-vis des jeux de données ainsi ciblés.
Ceci conclut le rapide aperçu des évolutions introduites par la version 2.0a du kit de démarrage OGDI (Open Gouvernment Data).
Comments
- Anonymous
December 22, 2011
The comment has been removed - Anonymous
December 22, 2011
L'objet de ce billet vise simplement à illustrer d'un point de vue technique la prise en charge conforme du format RDF au travers du service de données OData. L'exposition de l'ensemble de données Musées est ici faite de façon brute sans paramétrage particulier. Le chargeur de données de la solution OGDI offre une certaine souplesse en termes de paramétrage de façon à offrir un premier niveau de description adaptée. Pour autant, toutes les contributions sur ce socle ouvert Open Source sont les bienvenues de façon à traduire dans le chargement et ensuite dans l'exposition les principes que vous rappelez ici pour le bénéfice de tous. Si la fondation protocolaire OData permet de s'ouvrir aujourd'hui à un écosystème de consommateurs (applications et kits de développement/bibliothèques) des plus vastes, il nous parait important, dans le même temps, de considérer d'autres approches d'exposition et de requêtage des données ouvertes et de proposer dans ces contextes une solution pertinente.