Blogabriel

Pour m’essayer concrètement au web des données, j’ai publié mon fichier FOAF. Il est ici.

Pour valider sa syntaxe, sa conformité RDF, on peut utiliser le Validator du W3C. Le résultat peut prendre la forme de triples validés et/ou de graphe.

Dans toutes les pages de ce blog, on trouve la ligne suivante dans le header :

 <link rel="meta" type="application/rdf+xml" title="FOAF" href="http://www.kepeklian.com/sem/foaf.rdf" />

Ca permet aux plugin sémantiques de Firefox de se déclencher.

Voici quelques outils qui permettent de visualiser les données liées :

* captsolo
* Talis

Twitter propose un accès FOAF.

Voici la traduction française en 10 posts, respectant la découpe en section de l’original, du tutoriel How to Publish Linked Data on the Web publié par Chris Bizer (Web-based Systems Group, Freie Universität Berlin, Germany), Richard Cyganiak (Web-based Systems Group, Freie Universität Berlin, Germany) et Tom Heath (Knowledge Media Institute, The Open University, Milton Keynes, UK).

Ce document explique la façon de publier des données liées sur le Web. Après un aperçu général de la notion de données liées, plusieurs recettes pratiques sont présentées pour la publication d’information sous forme de données liées sur le Web.

• la section 1 introduit la problématique.
• la section 2 énonce les principes de base des données liées.
• la section 3 fournit des conseils pratiques sur la façon de nommer les ressources avec des références URI,
• la section 4 examine des termes bien connus de vocabulaires et de sources de données qui devraient être réutilisé pour représenter de l’information,
• la section 5 explique quelles informations doivent être incluses dans les descriptions RDF qui sont publiés sur le Web,
• la section 6 donne des conseils pratiques sur la façon de générer des liens entre les données RDF à partir de sources de données différentes,
• la section 7 présente plusieurs recettes complètes pour l’édition de différents types d’information comme données liées sur le Web à l’aide des outils liés publication des données existantes,
• la section 8 concerne le test et le débogage de sources de données liées,
• la la section 9 donne un aperçu des mécanismes de substitution pour la découverte de données liées sur le Web.
• et la la section 10 qui vous fournit des liens vers des documents de référence et de nombreux outils.

Il reste encore 3 annexes dans le tutoriel dont la traduction suivra.

Voici la 10e partie de ma traduction du fameux tutorial  » How to Publish Linked Data on the Web? « écrit par Chris Bizer (Web-based Systems Group, Freie Universität Berlin, Germany), Richard Cyganiak (Web-based Systems Group, Freie Universität Berlin, Germany) et Tom Heath (Knowledge Media Institute, The Open University, Milton Keynes, UK).

10 – D’autres outils et d’autres lectures utiles

Pour plus d’information sur le Web lié (Linked Data) vous pouvez vous référez à ceci :

10.1 – Pour une vue d’ensemble et des bases théoriques

• Tim Berners-Lee: Linked Data (architecture note outlining the basic principles of Linked Data)
• Tim Berners-Lee: Giant Global Graph (blog post)
• Tim Berners-Lee: Browsable Data (slides about Linked Data)
• Tim Berners-Lee: Links on the Semantic Web (blog post stating the critical role of RDF links for the Semantic Web).
• LinkedData.org
• Wikipedia page on Linked Data
• ESW Wikipage on Linked Data
• W3C Semantic Web Activity Homepage
• W3C Semantic Web Frequently Asked Questions
• Paul Miller: Linked Data BOF and Linked Data once again (blog posts about the Linked Data sessions at WWW2007)
• Paul Miller: Opening the Silos – sustainable models for open data (video from the XTech 2007 – Open Data track)
• Michael K. Bergman: More Structure, More Terminology and (hopefully) More Clarity (contextualizes Linked Data in the overall development of the Web)
• Li Ding, Tim Finin: Characterizing the Semantic Web on the Web (ISWC2006 paper trying to measure the size of the Semantic Web, a bit outdated).
• Mike Bergman: Linked Data Comes of Age – LinkedData Planet and LDOW Set the Pace for 2008, February 2008.
• Uche Ogbuji: Real Web 2.0: Linking open data – Discover the community that sees Web 2.0 as a way to revolutionize information on the Web, IBM Developerworks, February 2008.

10.2 – Documentations techniques

• Leo Sauermann et al.: Cool URIs for the Semantic Web (tutorial on URI dereferencing and content-negotiation)
• Alistair Miles et al.: Best Practice Recipes for Publishing RDF Vocabularies (W3C draft on serving RDF vocabularies according to the Linked Data principles)
• Richard Cyganiak: Debugging Semantic Web sites with cURL (tutorial on how to test Semantic Web sites)
• Semantic Web Tools (listing of RDF stores and development tools)
• Christian Bizer, Daniel Westphal: Developers Guide to Semantic Web Toolkits (another list of RDF development tools)
• Semantic Web Crawling: a Sitemap Extension. The sitemap extension allows Data publishers can state where RDF is located and which alternative means are provided to access it (Linked Data, SPARQL endpoint, RDF dump).

10.3 – Projets et expériences pratiques dans la publication de données liées

• Linking Open Data Project (W3C SWEO community effort that publishes as RDF and interlinks open data sources such as Geonames, DBpedia, Musicbrainz, …. See also List of public Linked Data sources on the Web)
• Christian Bizer et al.: Interlinking Open Data on the Web (poster) (Overview about the W3C SWEO Linking Open Data project)
• Christian Bizer et al.: The RDF Book Mashup: From Web APIs to a Web of Data (Slides). (SFSW2007 paper)
• Marcus Cobden et al.: ECS URI System (Documentation on how the ECS department of the University of Southampton implements Linked Data on their department website.
• A similar example is given be the website of the Web-based Systems Group @ Freie Universität Berlin
• Christian Bizer et al: DBpedia – Querying Wikipedia like a Database (Slides). (WWW2007 Dev-Track presentation)

10.4 – Des clients de données liées

• Tabulator RDF Browser (Linked Data browser implemented by Tim Berners-Lee et al.)
• Tim Berners-Lee et al.: Tabulator: Exploring and Analyzing Linked Data on the Semantic Web (Slides) (SWUI2007 paper about the Tabulator Linked Data browser and its data retrieval algorithms)
• DISCO Hyperdata Browser (a simple Linked Data browser provided by Freie Universität Berlin)
• OpenLink Data Web Browser (Linked Data browser provided by OpenLink)
• Objectviewer (Linked Data browser provided by SemanticWebCentral)
• Semantic Web Client Library (Java framework for building Linked Data clients)
• Semantic Web client for SWI Prolog (This is a small Prolog program allowing to see the semantic-web as a single graph, and to browse it, similar to the Semantic Web Client Library)
• Tabulator AJAR RDF library for Javascript (retrieval engine underlying the Tabulator browser)
• OpenLink Ajax Toolkit (includes both a Data Access Layer of RDF, SQL, and XML called Ajax Database Connectivity and a collection of RDF aware controls covering: Graph Visualizers, TimeLines, Tag Clouds, Pivot Tables, and more)
• See also List of Linked Data Clients (maintained by the W3C Linking Open Data project)

10.5 – Des moteurs de recherche dans le Web des données liées

• Falcons developed by IWS China, currently indexes 7 million RDF documents.
• Sindice developed by DERI Ireland, currently indexes over 20 million RDF documents. See also their ISWC2007 paper Sindice.com: Weaving the Open Linked Data
• Watson developed by KMi, UK. See also the list of papers and presentations about Watson
• Semantic Web Search Engine (SWSE) developed by DERI Ireland. See also their paper MultiCrawler: A Pipelined Architecture for Crawling and Indexing Semantic Web Data.
• Swoogle developed by ebiquity group at UMBC USA, currently indexes 2.3 million RDF documents. See also their papers about Swoogle .

Aram Mardirossian, docteur en histoire du droit, spécialiste du droit canonique de l’Antiquité tardive et du Haut Moyen Age, nous offre une série d’émissions de radio que l’on peut écouter sur Radio Ayp en Ile-de-France sur 99.5 et partout sur Internet http://www.radio-aypfm.com/. Le sujet de cette série qui a débuté le 5 janvier 2010 est l’histoire riche et mouvementée de l’Eglise d’Arménie, depuis le début du IVe, avec la conversion du Roi Tiridate IV jusqu’au milieu du XIe siècle en 1064, date de la prise d’Ani par les Turcs Seldjoukides.

Les trois parties que composent les émissions successives sont « des légendes apostoliques à la conversion de Tiridate le Grand », « les querelles christologiques » puis « l’église arménienne sous la domination arabe ». Il s’agit d’une chronique exposée avec beaucoup de rigueur et destinée à être accessible au plus grand nombre. Les faits historiques sont présentés à partir de toutes les sources disponibles.

Les émissions peuvent être aussi podcastées depuis le site de Radio Ayp.

Voici la 9e partie de ma traduction du fameux tutorial  » How to Publish Linked Data on the Web? « écrit par Chris Bizer (Web-based Systems Group, Freie Universität Berlin, Germany), Richard Cyganiak (Web-based Systems Group, Freie Universität Berlin, Germany) et Tom Heath (Knowledge Media Institute, The Open University, Milton Keynes, UK).

9 – Découverte de données liées sur le Web

La façon habituelle de découvrir des données liées dans le Web consiste à suivre les liens RDF au sein des données que le client connait déjà. Afin de rendre la poursuite de la découverte encore plus aisée, les fournisseurs d’information peuvent décider de mettre en oeuvre des mécanismes de découverte complémentaires :

Ping le Web sémantique

Ping le Web sémantique est un service d’enregistrement des documents RDF dans le Web, il est utilisé par plusieurs autres services et applications clientes. Vous pouvez ainsi augmenter les chances de faire découvrir vos données par l’enregistrement de votre URI avec « Ping le Web sémantique ».

Lien HTML d’auto-découverte

Il est également judicieux dans de nombreux cas d’établir des liens depuis des pages Web existantes vers vos données RDF, par exemple en mettant dans votre page d’accueil personnalisée des liens vers votre profil FOAF. Ces liens peuvent être définis en utilisant l’élément HTML dans l’en-tête de votre page HTML.

<link rel="alternate" type="application/rdf+xml" href="link_to_the_RDF_version" />

Les éléments HTML sont utilisés par des extensions du navigateur comme Piggybank et Semantic Radar pour découvrir des données RDF dans le Web.

Semantic Web Crawling : un extension de sitemap

Semantic Web Crawling : une extension de Sitemap. L’extension de sitemap permet aux éditeurs de données de faire état de l’endroit où est situé le RDF et de savoir quels moyens alternatifs sont prévus pour y accéder (données liées, SPARQL endpoint, dump RDF). Les clients du Web sémantique et les robots du Web sémantique peuvent utiliser cette information pour accéder aux données RDF de la manière la plus efficace pour la tâche qu’ils ont à accomplir.

Liste de Dataset dans le wiki ESW

Afin de faciliter la découverte vos données, non seulement pour les machines mais aussi pour les humains, vous devez insérer votre dataset à la liste Dataset du wiki ESW. N’hésitez pas à inclure quelques exemples d’URI de ressources intéressantes de votre ensemble de données (dataset), de sorte que les gens aient des points de départ pour la navigation.

Voici la 8e partie de ma traduction du fameux tutorial  » How to Publish Linked Data on the Web? « écrit par Chris Bizer (Web-based Systems Group, Freie Universität Berlin, Germany), Richard Cyganiak (Web-based Systems Group, Freie Universität Berlin, Germany) et Tom Heath (Knowledge Media Institute, The Open University, Milton Keynes, UK).

8 – Test et débogage de données liées

Après avoir publié vos informations sous la forme de données liées dans le Web, vous devez maintenant vérifier si elles peuvent être correctement consultées.

Un moyen simple pour tester cela consiste à soumettre plusieurs de vos URI au service de validation Vapour, celui-ci génère un rapport détaillé sur la façon dont vos URI réagissent aux différentes requêtes HTTP.

A côté de cela, il est également important de voir si vos informations s’affichent correctement dans différents navigateurs de données liées et si les navigateurs peuvent suivre les liens au sein de vos données RDF. Prenez donc plusieurs URI de votre ensemble de données et entrer les dans la barre de navigation des navigateurs suivants qui sont liés de données :

• Tabulator. Si Tabulator prend beaucoup de temps avant d’afficher vos informations, c’est un indicateur que vos graphes RDF sont trop grands et doivent être fractionnés. Tabulator fait aussi quelque inférence de base sur des données du Web, sans effectuer les contrôles de cohérence. Aussi, si Tabulator se comporte étrangement, cela pourrait indiquer des problèmes avec des déclarations rdfs:subClassOf et rdfs:subPropertyOf dans les schémas RDFS et OWL utilisés dans vos données.
• Marbres
• OpenLink RDF Browser
• Disco. Le navigateur Disco prend un temps de 2 secondes pendant la récupération des données sur le Web. Donc, ça peut être un indicateur que votre serveur est trop lent, si Disco n’affiche pas correctement vos données.

Si vous rencontrez des problèmes, vous devez effectuer les opérations suivantes :

1. Testez avec cURL si le déréférencement de vos URI conduit à corriger les réponses HTTP. Richard Cyganiak a publié un tutoriel sur le débogage sémantique des sites Web avec cURL, il vous conduit dans le processus.
2. Utilisez le service de validation du W3C RDF pour vous assurer que votre service offre valable RDF / XML.

Si vous n’arrivez pas à comprendre par vous-même ce qui ne va pas, demandez de l’aide sur la liste de diffusion Open Linking Data.

Voici la 7e partie de ma traduction du fameux tutorial  » How to Publish Linked Data on the Web? « écrit par Chris Bizer (Web-based Systems Group, Freie Universität Berlin, Germany), Richard Cyganiak (Web-based Systems Group, Freie Universität Berlin, Germany) et Tom Heath (Knowledge Media Institute, The Open University, Milton Keynes, UK).

7. Recettes pour exposer des informations sous la forme de données liées

Ce chapitre fournit des recettes pratiques pour la publication de différents types d’informations sous la forme de données liées. Les informations doivent remplir au moins les conditions suivantes pour être considérées comme « publiées en tant que données liées sur le Web » :

• Les choses doivent être identifiées avec des URI HTTP déréférenceables.
• Si un tel URI est déréférencé en demandant un type MIME application/rdf+xml, une source de données doit retourner une description RDF/XML de la ressource identifiée.
• les URI qui identifient les ressources non-informatives doivent être créés de l’une de manières qui suit : soit la source de données doit renvoyer une réponse HTTP 303 qui contient une redirection HTTP vers une ressource d’information décrivant la ressource non-informative, tel que discuté précédemment dans le présent document. Ou l’URI de la ressource non-informative doit être obtenue en prenant l’URI de la ressource d’information et en ajoutant un fragment d’identifiant (#foo, par exemple), tel que discuté dans la recette 7.1.
• Outre les liens RDF aux ressources d’une même source de données, des descriptions RDF devraient également contenir des liens RDF vers des ressources fournies par d’autres sources de données, de sorte que les clients puissent naviguer sur le Web de données dans son ensemble en suivant les liens RDF.

Parmi les recettes suivantes, lesquelles correspondent à vos besoins ?

• Quelle quantité de données voulez-vous servir ? Si vous voulez seulement de publier plusieurs centaines de triplets RDF, vous voudrez peut-être les servir dans un fichier RDF statique en utilisant la Recette 7.1. Si votre ensemble de données est plus grand, vous pourrez vouloir le charger dans un magasin RDF (en anglais : RDF store) propre et mettre le Pubby Linked Data Interface en face de celui-ci tel que décrit dans la recette 7.3.
• Comment vos données sont-elles actuellement stockées ? Si vos informations sont stockées dans une base de données relationnelle, vous pouvez utiliser D2R Server comme indiqué dans la recette 7.2. Si l’information est accessible via une API, vous pourriez mettre en œuvre un wrapper autour de cette API comme décrit dans la recette 7.4. Si votre information est représentée dans un autre format tel que Microsoft Excel, CSV ou BibTeX, vous devrez d’abord le convertir en RDF comme décrit dans la recette 7.3.
• Combien de fois vos données doivent-elles changées ? Si vos données changent fréquemment, vous préférez les approches qui peuvent générer des vues sur vos données RDF, tels que D2R Server (Recette 7.2), ou les wrappers (Recette 7.4).

Après avoir publié vos informations sous forme de données liées, vous devez vous assurer qu’il y a des liens RDF externes pointant vers des URI de votre ensemble de données, de sorte que les navigateurs RDF et les robots puissent trouver vos données. Il existe deux méthodes de base pour y parvenir :

1. Ajouter plusieurs liens RDF à votre profil FOAF qui pointent des URI identifiants des ressources centrales de votre dataset. En supposant que quelqu’un dans le monde vous connaisse et note votre profil FOAF, votre nouvel ensemble de données sera désormais accessible via des liens RDF.
2. Convaincre les propriétaires de sources de données liées d’auto-générer des liens RDF vers des URI de votre dataset. Ou pour faciliter les choses pour le propriétaire d’un autre ensemble de données (en anglais dataset), créez des liens RDF vous-même et envoyer les lui, il ne lui plus qu’à les fusionner avec son ensemble de données. Un projet qui est extrêmement ouvert à la création de liens vers d’autres sources de données RDF est le projet communautaire DBpedia. Il suffit juste d’annoncer votre source de données sur la liste de diffusion DBpedia ou d’envoyer un ensemble de liens RDF à la liste.

7.1 – Servir des fichiers statiques

La plus simple façon de servir les données liées est de produire des fichiers RDF statiques et les télécharger sur un serveur web. Cette méthode est généralement choisie dans les situations où

• les fichiers RDF sont créés manuellement, par exemple lors de la publication personnelle fichiers FOAF ou de vocabulaires RDF ou
• les fichiers RDF sont produits ou exportés par un bout de logiciel qui n’a que des sorties fichiers.

Il y a plusieurs aspects à considérer :

Configuration du serveur pour des types MIME correct

Les anciens serveurs Web ne sont parfois pas configurés pour renvoyer le bon type MIME lorsqu’ils doivent servir des fichiers RDF/XML. Les navigateurs de données liées peuvent ne pas reconnaitre les données RDF servies de cette façon parce que le serveur fait valoir que ce n’est pas RDF/XML, mais du texte brut. Pour savoir si votre serveur a besoin d’une correction de ce problème, utilisez l’outil cURL et suivez les étapes décrites dans ce tutoriel.

La façon de réparer cela dépend du type de votre serveur web. Dans le cas d’Apache, ajoutez cette ligne au fichier de configuration httpd.conf, ou à un fichier. Htaccess dans le répertoire du serveur web où les fichiers RDF sont placés :

AddType application/rdf+xml .rdf

Cela indique à Apache de servir les fichiers ayant une extension .rdf en utilisant le bon type MIME pour RDF/XML, à savoir application/rdf+xml. Remarque, cela signifie que vous avez nommer vos fichiers avec l’extension .rdf.

Pendant que vous y êtes, vous pouvez également ajouter ces lignes pour faire en sorte que votre serveur web soit prêt pour d’autres syntaxes RDF (N3 et Turtle) :

AddType text/rdf+n3;charset=utf-8 .n3
AddType application/x-turtle .ttl

Taille du fichier

La publication de pages HTML de très grandes tailles n’est pas recommandée, car elles se chargent très lentement dans les navigateurs et consomment inutilement de la bande passante. La même chose est vraie quand il s’agit de publication de données liées : vos fichiers RDF ne devraient pas être plus grand que, disons, quelques centaines de kilo-octets. Si vos fichiers sont plus volumineux et décrivent de multiples ressources, vous devez les diviser en plusieurs fichiers RDF, ou l’utilisation Pubby tel que c’est décrit dans la recette 7.3 et ainsi les servir par morceaux.

Lorsque vous servez plusieurs fichiers RDF, assurez-vous qu’ils sont liés les uns aux autres par le biais de triplets RDF qui impliquent des ressources décrites dans les différents fichiers.

Le choix des URI pour les ressources non-informatives

L’approche de fichiers statiques ne supporte pas les 303 redirections nécessaires pour les URI des ressources non-information. Heureusement il existe une autre méthode conforme aux normes de nommer les ressources non-information, qui fonctionne très bien avec les fichiers statiques RDF, mais a un inconvénient, nous discuterons plus tard. Cette méthode est fondée sur les URI avec dièse.

Lorsque vous servez d’un fichier statique RDF à, disons, http://example.com/people.rdf, vous devez alors le nom de la non-information sur les ressources décrits dans le fichier en ajoutant un identificateur de fragment d’URI du fichier. L’identifiant doit être unique dans le fichier. De cette façon, vous vous retrouvez avec des URI comme cela pour votre non-ressources d’information :

• http://example.com/people.rdf#alice
• http://example.com/people.rdf#bob
• http://example.com/people.rdf#charlie

Cela fonctionne parce que les clients HTTP déréférencent les URI avec dièse en séparant la partie qui suit le dièse et en déréférençant l’URI résultant. Un navigateur de données liées va ensuite se scruter la réponse (le fichier RDF dans ce cas) et trouver des triplets qui en disent plus sur la ressource non-informative, obtenant ainsi un effet assez similaire à la redirection 303.

L’inconvénient de cette approche est que le nommage des URI n’est pas très « cool » au sens des critères énoncés dans la section 3. Il y a une référence à un format de représentation spécifique dans les identifiants (l’extension .rdf). Et si plus tard vous décidez de renommer le fichier RDF, ou si vous décidez de diviser vos données en plusieurs fichiers, alors tous les identifiants changeront et les liens existants casseront.

C’est pourquoi vous ne devriez utiliser cette approche que si la structure globale et la taille de l’ensemble de données ne risquent pas de changer beaucoup dans l’avenir, ou pour une solution temporaire pour des données transitoires où la stabilité des liens n’est pas si importante.

Extension de la recette pour des redirections 303 et la négociation de contenu

Cette approche peut être étendue pour utiliser des redirections 303 et même pour permettre la négociation de contenu, si vous êtes prêt à faire toutes sortes de gymnastique. Malheureusement, ce processus dépend de votre serveur web et de sa configuration. Le W3C a publié plusieurs recettes qui montrent comment faire avec un serveur web Apache : Best Practice Recipes for Publishing RDF Vocabulaires. Le document est officiellement destiné aux éditeurs de vocabulaires RDF, mais les recettes marchent aussi pour d’autres types de données RDF servies à partir de fichiers statiques. Notez qu’au moment d’écrire il reste un problème avec la négociation de contenu dans ce document qui pourrait être résolu en passant le serveur Apache du mode mod_rewrite à celui de mod_negotiation.

7.2 – Servir des bases de données relationnelles

Si vos données sont stockées dans une base de données relationnelle, c’est généralement une bonne idée de les y laisser et de publier uniquement une vue sur les données de votre base sous la forme de données liées.

Un outil qui permet de servir des vues de bases de données relationnelles sous forme de données liées est D2R Server. D2R Server repose sur un mapping déclaratif entre les schémas de la base et les termes RDF ciblés. Sur la base de ce mapping, D2R Server sert une vue de données liées sur votre base de données et fournit un endpoint SPARQL pour la base de données.

AddType text/rdf+n3;charset=utf-8 .n3
AddType application/x-turtle .ttl

Il existe plusieurs serveurs D2R ligne, par exemple Berlin DBLP Bibliography Server, Hannover DBLP Bibliography Server, Web-based Systems @ FU Berlin Group Server ou EuroStat Countries and Regions Server.

La publication d’une base de données relationnelles sous la forme de données liées comporte habituellement les étapes suivantes :

1. Téléchargez et installez le logiciel serveur comme indiqué dans la section Démarrage rapide de la page d’accueil D2R Server.
2. Ayez un D2R serveur pour générer automatiquement un mapping D2RQ à partir du schéma de votre base de données (voir Démarrage rapide).
3. Personnalisez le mapping en remplaçant les termes générés automatiquement par des termes de vocabulaires RDF bien-connus et accessibles au public.
4. Ajoutez votre nouvelle source de données dans la liste des ensembles de données du Wiki ESW dans la catégorie « données liées » et dans la liste « endpoint SPARQL », puis établissez plusieurs liens RDF à partir de votre profil FOAF vers des URI de ressources centrales au sein de votre nouvelle source de données afin que les robots puissent découvrir vos données.

Alternativement, vous pouvez aussi utiliser :

1. OpenLink Virtuoso pour publier votre base de données relationnelles à la façon de données liées.
   • Vues RDF de Virtuoso – Guide de démarrage sur la façon de mapper votre base de données relationnelle avec RDF et
   • Déploiement de données liées sur la façon d’obtenir un déréférencement d’URI et une négociation de contenu en place.
2. Triplify, un petit plugin pour les applications Web, qui révèle les structures sémantiques encodées dans les bases de données relationnelles en rendant le contenu disponible sous la forme de base de données RDF, JSON ou de données liées.

7.3 – Exposer d’autres types d’informations

Si vos informations sont actuellement représentées dans des formats CSV, Microsoft Excel, ou BibTeX et si vous voulez les servir comme des données liées sur le Web, voici des bonnes idées à réaliser dans ce qui suit :

• Convertissez vos données en RDF en utilisant un outil de RDFisation. Il y a deux endroits où de tels outils sont répertoriés : ConverterToRdf qui est mis à jour dans le wiki ESW, et RDFizers maintenu par l’équipe de SMILE.
• Après la conversion, stockez vos données dans un référentiel RDF. Une liste des référentiels RDF est maintenue dans le wiki ESW.
• Idéalement, le référentiel RDF choisi est accompagné d’une interface de données liées qui prend soin de rendre accessibles vos données Web. Comme de nombreux référentiels RDF n’ont pas encore implémenté des interfaces pour les données liées, vous pouvez également choisir un référentiel qui fournit un endpoint SPARQL et met à disposition Pubby comme interface de données liées en front de votre endpoint SPARQL.

L’approche décrite ci-dessus est entre autres adoptée par le projet DBpedia. Ce projet utilise des scripts PHP pour extraire des données structurées à partir de pages Wikipédia. Ces données sont ensuite converties en RDF et stockés dans un référentiel Virtuoso OpenLink qui fournit un endpoint SPARQL. Afin d’obtenir une vue sous forme de données liées, Pubby est placé en front pour exploiter l’endpoint SPARQL.

Si votre ensemble de données est de taille suffisamment petite pour s’adapter complètement dans la mémoire principale du serveur Web, alors vous pouvez vous passer d’un repository RDF, et utiliser l’option conf:loadRDF de Pubby pour charger les données RDF à partir d’un fichier RDF directement dans Pubby. Cela pourrait être plus simple, mais à la différence d’un dépôt réel RDF, Pubby tient tout en mémoire principale et ne propose pas d’endpoint SPARQL.

7.4 – Mise en œuvre autour des applications existantes ou des API Web

Un grand nombre d’applications Web ont commencé à rendre leurs données disponibles sur le Web au travers d’API Web. Des exemples de sources de données fournissant de tels API sont donnés par des entreprises comme eBay, Amazon, Yahoo, Google et Google Base. Une liste plus complète des API se trouve sur Programmable Web. Différentes API fournissent différentes requêtes et interfaces d’extraction et renvoient les résultats en utilisant un certain nombre de formats différents tels que XML, JSON ou ATOM. Ceci conduit à trois limitations générales des API Web :

• Leur contenu ne peut pas être exploré par les moteurs de recherche
• Les API Web ne peuvent être accédés à l’aide de navigateurs de données génériques
• Des Mashups ont été réalisés pour un certain nombre de sources de données et ne peuvent pas profiter des nouvelles sources de données qui apparaissent sur le Web.

Ces limitations peuvent être surmontées par la mise en œuvre de wrappers de données liées sur la base des API. En général, les wrappers de données liées procèdent comme ceci :

1. Ils assignent des URI HTTP aux ressources non-informatives pour lesquelles l’API qui fournit des données.
2. Lorsque l’un de ces URI est déréférencé en demandant un type application/rdf+xml, le wrapper réécrit la demande du client en une requête pour l’API sous-jacente.
3. Les résultats de la requête de l’API sont transformés en RDF et renvoyés au client.

Exemples de wrappers de données liées notamment :

Le RDF Book Mashup

Le RDF Book Mashup expose l’information sur les livres, leurs auteurs, les critiques et les librairies en ligne, et les rend disponible sous forme RDF sur le Web. Le RDF Book Mashup assigne un URI HTTP pour chaque produit qui a un numéro ISBN. Lorsque l’un de ces URI est déréférencé, le Mashup demande des données sur le livre, son auteur ainsi que des notes de lecture et des offres commerciales à l’aide des API d’Amazon et des API Google Base. Ces données sont ensuite transformés en RDF et retournés au client.

Le RDF Book Mashup est implémenté comme un petit script PHP qui peut être utilisé comme modèle pour la mise ou point d’autres wrappers similaires dans d’autres API Web. Vous trouverez plus d’information sur le Book Mashup et la relation entre les API Web et les données liées en général dans The RDF Book Mashup: From Web APIs to a Web of Data (diapositives).

Exporteurs SIOC pour WordPress, Drupal, phpBB

Le projet SIOC a développé des wrappers de données liées pour les moteurs de plusieurs blogs populaires, des systèmes de gestion de contenu et des forums de discussion. Voyez exporteurs SIOC pour une mise à jour la liste de leurs wrappers. Le projet fournit également un API d’exportation en PHP qui permet aux développeurs de créer d’autres outils d’export SIOC sans qu’il soit nécessaire d’entrer dans des détails techniques sur la façon dont l’information est représentée en RDF.

Virtuoso Sponger

Virtuoso Sponger est un cadre pour le développement de wrappers de données liées (appelés cartouches) autour de différents types de sources de données. La source de données peut varier depuis la page HTML contenant des données structurées jusqu’aux API Web. Voyez Injecting Facebook Data into the Semantic Data Web pour une démonstration sur la façon utilisée par Sponger pour générer une vue de données liées sur Facebook.

Voici la 6e partie de ma traduction du fameux tutorial  » How to Publish Linked Data on the Web? « écrit par Chris Bizer (Web-based Systems Group, Freie Universität Berlin, Germany), Richard Cyganiak (Web-based Systems Group, Freie Universität Berlin, Germany) et Tom Heath (Knowledge Media Institute, The Open University, Milton Keynes, UK).

6 – Comment définir des liens vers d’autres sources de données RDF

Les liens RDF permettent aux navigateurs et aux robots d’exploration de naviguer parmi les sources de données et de découvrir des données supplémentaires.

Le domaine d’application permet de déterminer quelles propriétés RDF sont utilisées comme prédicats. Par exemple, les propriétés des liens couramment utilisées dans le domaine de description des personnes sont foaf:knows, foaf:based_near et foaf:topic_interest. Des exemples combinant ces propriétés avec des valeurs de propriété de DBpedia, de la bibliographie DBLP et du RDF Book Mashup peuvent être trouvés dans les profils FOAF de Tim Berners-Lee et d’Ivan Herman.

Il est de pratique courante d’utiliser la propriété owl:sameAs pour exprimer qu’une autre source de données donne aussi des informations sur une ressource non-informative particulière. Un lien owl:sameAs indique que deux références URI se rapportent à la même chose. Ainsi owl:sameAs est utilisé pour exprimer la correspondance entre différents alias URI (voir section 2.1). On peut voir des exemples d’utilisation de owl:sameAs pour indiquer que deux URI parlent de la même chose dans le profil FOAF de Tim qui stipule que http://www.w3.org/People/Berners-Lee/card#i identifie la même ressource que http://www4.wiwiss.fu-berlin.de/bookmashup/persons/Tim+Berners-Lee et http://www4.wiwiss.fu-berlin.de/dblp/resource/person/100007. D’autres exemples d’utilisation se trouvent dans DBpedia et le serveur DBLP de Berlin.

Les liens RDF peuvent être définis manuellement, ce qui est généralement le cas pour les profils FOAF, mais ils peuvent aussi être générés par des algorithmes automatisés de liaison. Cette approche est habituellement prises pour interconnecter les grands ensembles de données.

6.1 – Configurer manuellement des Liens RDF

Avant de pouvoir mettre des liens RDF manuellement, vous devez savoir quelque chose sur les ensembles de données avec lesquels vous souhaitez établir un lien. Afin d’obtenir un aperçu des différents ensembles de données qui peuvent être utilisés comme cibles de liens consultez la liste des ensembles de données liées et ouvertes (Linking Open Data Dataset list). Une fois que vous avez identifié des ensembles de données particuliers comme des cibles de lien appropriées, vous pouvez rechercher manuellement dans ces URI les références sur lesquelles vous souhaitez créer un lien. Si une source de données ne fournit pas une interface de recherche, comme par exemple un SPARQL endpoint ou un formulaire HTML, vous pouvez utiliser des navigateurs de données liées comme Tabulator ou Disco pour explorer l’ensemble des données et trouver les bons URI.

Vous pouvez également utiliser des services tels que Uriqr ou Sindice pour rechercher des URI existants et choisir le plus populaire si vous trouvez plusieurs candidats. Uriqr vous permet de trouver des URI pour les personnes que vous connaissez, simplement en cherchant avec leur nom. Les résultats sont classés en fonction du rang de référencement de l’URI particulier dans les documents RDF du Web, mais vous devrez tout de même mettre un peu d’intelligence humaine dans le choix de l’URI le plus approprié à utiliser. Sindice indexe le Web sémantique et peut vous indiquer quelles sources mentionnent un URI donné. Ainsi, ce service peut vous aider à choisir l’URI le plus populaire pour un concept.

Rappelez-vous que les sources de données sont susceptibles d’utiliser des redirections HTTP-303 pour rediriger des clients identifiants des URI de ressources non-informatives vers des URI identifiant les ressources d’information qui décrivent les ressources non-informatives. Dans ce cas, assurez-vous que vous liez bien la référence d’URI identifiant la ressource non-informative, et non le document sur ce sujet.

6.2 – Auto-production de Liens RDF

L’approche décrite ci-dessus n’est pas envisageable sur des masses de données, par exemple l’interconnexion de 70.000 lieux dans DBpedia avec leurs entrées correspondantes dans Geonames. Dans ce cas, il est logique d’utiliser un algorithme de couplage automatisé d’enregistrements pour générer les liens entre les sources de données RDF.

Le couplage d’enregistrements (record linkage) est un problème bien connu dans la communauté bases de données. Le projet Linking Open Data recueille des données relatives à l’usage des algorithmes de couplage d’enregistrements dans le contexte des données liées sur la page wiki Equivalence Mining.

On est encore un manque de bons outils faciles à utiliser pour générer automatiquement des liens RDF. Dans la pratique, il est donc habituel de mettre en œuvre des algorithmes de couplage d’enregistrements sur des ensembles de données spécifiques pour générer des liens entre les sources de données RDF. Nous décrivons maintenant deux classes d’algorithmes :

Les algorithmes basés sur des modèles (pattern based)

Dans de nombreux domaines, il existe des règles de nommage reconnues. Par exemple, dans le domaine de la publication il y a les numéros ISBN, dans le domaine financier, il existe les identificateurs ISIN. Si ces identifiants sont utilisés pour former une partie des URI HTTP pour identifier des ressources particulières, alors il est possible d’utiliser des algorithmes basé sur des modèles simples pour générer des liens entre ces ressources RDF.

Un exemple d’une source de données qui utilise les numéros ISBN dans la constitution de ses URI est le RDF Book Mashup, qui, utilise par exemple l’URI http://www4.wiwiss.fu-berlin.de/bookmashup/books/0747581088 pour identifier le livre « Harry Potter and the Half-Blood Prince ». On voit bien que si on a le numéro ISBN dans ces URI, il était facile pour DBpedia de générer des liens owl:sameAs entre les livres dans DBpedia et le Mashup Book. DBpedia utilise l’algorithme basée sur le modèle suivant :

1. Itérer dans DBpedia sur tous les livres qui ont un numéro ISBN.
2. Créer un lien owl:sameAs entre l’URI d’un livre dans DBpedia et son URI correspondant dans Book Mashup en utilisant le modèle suivant pour les URI Book Mashup : http://www4.wiwiss.fu-berlin.de/bookmashup/books/ {numéro ISBN}.

L’exécution de cet algorithme pour tous les livres dans DBpedia crée plus de 9000 liens RDF, qui sont reliés avec l’ensemble de données DBpedia. Par exemple, le lien résultat pour le livre de Harry Potter est le suivant :

<http://dbpedia.org/resource/Harry_Potter_and_the_Half-Blood_Prince>
    owl:sameAs <http://www4.wiwiss.fu-berlin.de/bookmashup/books/0747581088>

Algorithmes plus complexes fondés sur les propriétés

Dans les cas où il n’existe aucun identifiant commun entre les ensembles de données, il est nécessaire d’employer des des algorithmes de couplage plus complexes basées sur les propriétés. Nous décrivons ici deux algorithmes :

1. Interconnexion entre DBpedia et Geonames. Des informations sur des lieux géographiques sont présentes dans la base de données Geonames, ainsi que dans DBpedia. Afin d’identifier les lieux qui apparaissent dans les deux ensembles de données, l’équipe de Geonames utilise une heuristique basée sur les propriétés qui repose sur le titre de l’article ainsi que sur des informations sémantiques, comme la latitude et la longitude, mais aussi le pays, la division administrative, le type d’entité, la population et des catégories. L’exécution de cette heuristique entre les deux sources de données a permis de trouver 70500 correspondances qui ont été fusionnées comme des liens Geonames owl:sameAs avec l’ensemble de données DBpedia de la même façon qu’avec l’ensemble de données Geonames.
2. Interconnexion entre Jamendo et MusicBrainz. Vous pouvez vous référer au post du blog d’Yves Raimond relatif à son approche de l’articulation entre Jamendo et MusicBrainz.

Voici la 5e partie de ma traduction du fameux tutorial  » How to Publish Linked Data on the Web? « écrit par Chris Bizer (Web-based Systems Group, Freie Universität Berlin, Germany), Richard Cyganiak (Web-based Systems Group, Freie Universität Berlin, Germany) et Tom Heath (Knowledge Media Institute, The Open University, Milton Keynes, UK).

5 – Que dois-je retourner en tant que description RDF pour une URI ?

En supposant que nous ayons parfaitement exprimé toutes nos données à l’aide de triplets RDF : quel triplet devrait être retourné (après une redirection 303) en réponse au déréférencement de l’URI identifiant une ressource non-informative ?

1. La description : la représentation doit inclure tous les triplets de votre ensemble de données dont l’URI de la ressource est le sujet. Ceci est la description immédiate de la ressource.
2. Les liens arrière (backlinks) : la représentation devrait aussi inclure tous les triplets de votre ensemble de données dont l’URI de la ressource est l’objet. Ces triplets sont apparemment redondants, en effet, ils peuvent déjà être trouvés par l’URI de leur sujet, mais ça permet aux navigateurs et aux robots d’exploration (crawlers) d’emprunter les liens dans les deux sens.
3. Les descriptions connexes : vous pouvez inclure toute information additionnelle sur les ressources connexes qui peuvent avoir un intérêt dans des scénarios types d’utilisation. Par exemple, vous souhaitez peut-être envoyer des informations sur un auteur avec celles qui concernent un de ses livres, car de nombreux clients intéressés par les livres peuvent également être intéressé par l’auteur. Une approche modérée est recommandée, car celle qui consiste à renvoyer un mégaoctet de RDF sera considéré comme excessive dans la plupart des cas.
4. Les métadonnées : la représentation devrait contenir toutes les métadonnées que vous souhaitez joindre à vos données publiées, comme par exemple l’URI identifiant l’auteur, mais aussi ceux sur les licences. Elles doivent être enregistrées comme des descriptions RDF de la ressource d’information qui décrit une ressource non-informative ; c’est-à-dire que le sujet des triplets RDF devrait être l’URI de la ressource d’information. En joignant des méta-informations à cette ressource d’information plutôt qu’à la ressource décrite lui-même ou à des déclarations spécifiques sur la ressource RDF (comme avec la réification RDF), cela apparentent très bien à l’utilisation des graphes nommés et du langage de requêtes SPARQL dans les applications clientes de données liées. Afin de permettre aux consommateurs des informations d’utiliser vos données dans des conditions juridiques claires, chaque document RDF devrait contenir une information sur la licence sous laquelle le contenu peut être utilisé. Référez-vous à Creative Commons ou Talis pour les licences standard.
5. La syntaxe : Il existe différentes manières de sérialiser les descriptions RDF. Votre source de données devrait au moins fournir une description RDF comme RDF/XML qui est la seule syntaxe officielle pour RDF. Comme RDF/XML n’est pas très lisible, votre source de données pourrait en outre fournir des descriptions Turtle lorsqu’on lui demande application/x-tortue comme mime-type. Dans les situations où vous pensez que les gens pourraient vouloir utiliser vos données avec des technologies XML telles que XSLT ou XQuery, il pourrait être également utile de recourir à une sérialisation Trix, puisque TriX fonctionne mieux avec ces technologies que RDF/XML.

Dans ce qui suit, nous donnons deux exemples de descriptions RDF qui respectent les règles ci-dessus. Le premier concerne le cas des informations sur l’auteur et la propriété servies par un propriétaire d’URI. Le deuxième concerne le cas d’informations non officielles servies par quelqu’un qui n’est pas le propriétaire de l’URI décrites.

5.1 – Description de l’autorité

L’exemple suivant montre une partie de la représentation en Turtle de la ressource d’information http://dbpedia.org/data/Alec_Empire. La ressource décrit le musicien allemand Alec Empire. En utilisant la terminologie de l’architecture du Web, il s’agit d’une description officielle telle qu’elle est servie après une redirection 303 par le propriétaire de l’URI http://dbpedia.org/resource/Alec_Empire. Les déclarations d’espace de noms ont été omises.

# Metadata and Licensing Information

<http://dbpedia.org/data/Alec_Empire>
    rdfs:label "RDF description of Alec Empire" ;
    rdf:type foaf:Document ;
    dc:publisher <http://dbpedia.org/resource/DBpedia> ;
    dc:date "2007-07-13"^^xsd:date ;
    dc:rights
        <http://en.wikipedia.org/wiki/WP:GFDL> .

# La description

<http://dbpedia.org/resource/Alec_Empire>
    foaf:name "Empire, Alec" ;
    rdf:type foaf:Person ;
    rdf:type <http://dbpedia.org/class/yago/musician> ;
    rdfs:comment
        "Alec Empire (born May 2, 1972) is a German musician who is ..."@en ;
    rdfs:comment
        "Alec Empire (eigentlich Alexander Wilke) ist ein deutscher Musiker. ..."@de ;
    dbpedia:genre <http://dbpedia.org/resource/Techno> ;
    dbpedia:associatedActs <http://dbpedia.org/resource/Atari_Teenage_Riot> ;
    foaf:page <http://en.wikipedia.org/wiki/Alec_Empire> ;
    foaf:page <http://dbpedia.org/page/Alec_Empire> ;
    rdfs:isDefinedBy <http://dbpedia.org/data/Alec_Empire> ;
    owl:sameAs <http://zitgist.com/music/artist/d71ba53b-23b0-4870-a429-cce6f345763b> .

# Les liens arrière - Backlinks

<http://dbpedia.org/resource/60_Second_Wipeout>
    dbpedia:producer <http://dbpedia.org/resource/Alec_Empire> .
<http://dbpedia.org/resource/Limited_Editions_1990-1994>
    dbpedia:artist <http://dbpedia.org/resource/Alec_Empire> .

Notez que la description contient un lien owl:sameAs indiquant que http://dbpedia.org/resource/Alec_Empire et http://zitgist.com/music/artist/d71ba53b-23b0-4870-a429-cce6f345763b sont des URI alias se référant à la même ressource non-informative.

Pour faciliter aux clients de données liées la compréhension de la relation entre http://dbpedia.org/resource/Alec_Empire, http://dbpedia.org/data/Alec_Empire, et http://dbpedia.org/page/Alec_Empire, les URI peuvent être reliés entre eux en utilisant les propriétés rdfs:isDefinedBy et foaf:page comme c’est recommandé dans l’article Cool URI.

5.2 – Description non officielle

L’exemple suivant montre la représentation en Turtle dans la ressource d’information http://sites.wiwiss.fu-berlin.de/suhl/bizer/pub/LinkedDataTutorial/ChrisAboutRichard qui est publiée par Chris pour fournir des informations à propos de Richard. Notez qu’en Turtle, le raccourci syntaxique <> peut être utilisé pour se référer à l’URI du document actuel. Richard possède l’URI http://richard.cyganiak.de/foaf.rdf#cygri et est donc la seule personne autorisée qui peut fournir une description sur cet URI. Ainsi en utilisant la terminologie de l’architecture du Web, on dit que Chris fournit des informations non officielles sur Richard.

# Metadata and Licensing Information

<>
    rdf:type foaf:Document ;
    dc:author <http://www.bizer.de#chris> ;
    dc:date "2007-07-13"^^xsd:date ;
    cc:license <http://web.resource.org/cc/PublicDomain> .

# La description

<http://richard.cyganiak.de/foaf.rdf#cygri>
    foaf:name "Richard Cyganiak" ;
    foaf:topic_interest <http://dbpedia.org/resource/Category:Databases> ;
    foaf:topic_interest <http://dbpedia.org/resource/MacBook_Pro> ;
    rdfs:isDefinedBy <http://richard.cyganiak.de/foaf.rdf> ;
    rdf:seeAlso <> .

# Les liens arrière - Backlinks


<http://www.bizer.de#chris>
    foaf:knows <http://richard.cyganiak.de/foaf.rdf#cygri> .
<http://www4.wiwiss.fu-berlin.de/is-group/resource/projects/Project3>
    doap:developer <http://richard.cyganiak.de/foaf.rdf#cygri> .

Voici la 4e partie de ma traduction du fameux tutorial  » How to Publish Linked Data on the Web? « écrit par Chris Bizer (Web-based Systems Group, Freie Universität Berlin, Germany), Richard Cyganiak (Web-based Systems Group, Freie Universität Berlin, Germany) et Tom Heath (Knowledge Media Institute, The Open University, Milton Keynes, UK).

4 – Quels vocabulaires dois-je utiliser pour représenter l’information ?

Afin de faciliter le traitement de vos données aux applications clientes, vous devez réutiliser autant que faire se peut les termes de vocabulaires bien connus. Vous ne devez définir de nouveaux termes vous-même que si vous ne trouvez pas les termes requis dans les vocabulaires existants.

4.1 – Réutilisation des termes existants

L’ensemble des vocabulaires bien connus évolue dans la communauté du Web sémantique. Pour vérifier si vos données peuvent être représentées en utilisant des termes de ces vocabulaires avant d’en définir de nouveaux, commencez par regarder ici :

• Friend-of-a-Friend (FOAF), un vocabulaire pour décrire les personnes,
• Dublin Core (DC), pour définir les caractéristiques générales des métadonnées. Voir aussi le nouveau projet Domains and Ranges.
• Semantically-Interlinked Online Communities (SIOC), le vocabulaire pour représenter les communautés en ligne.
• Description of a Project (DOAP), pour décrire les projets.
• Simple Knowledge Organization System (SKOS), le vocabulaire pour représenter des taxonomies et des connaissances peu structurées.
• Music Ontology fournit les termes pour décrire les artistes, les albums et les pistes.
• Review Vocabulary, le vocabulaire pour représenter les examens.
• Creative Commons (CC), le vocabulaire pour décrire les conditions de licence.

Une liste plus complète de vocabulaires bien connus est maintenue par le projet communautaire W3C SWEO Linking Open Data dans le wiki ESW. Une liste des 100 espaces de nom RDF les plus courants (août 2006) est fournie par UMBC eBiquity Group.

Il est courant de mélanger des termes de vocabulaires différents. Nous recommandons particulièrement l’utilisation des propriétés rdfs:label et foaf:depiction chaque fois que possible, car ces termes sont bien utilisés par les applications clientes.

Si vous avez besoin des références URI pour des lieux géographiques, des domaines de recherche, des thèmes généraux, des artistes, des livres ou des CD, vous devriez considérer l’utilisation des URI de sources de données présentes dans le projet communautaire W3C SWEO Linking Open Data, par exemple, Geonames, DBpedia, Musicbrainz, dbtune ou RDF Book Mashup. Les deux principaux avantages à utiliser des URI à partir de ces sources de données sont les suivants :

1. Les URI sont déréférençables, cela signifie qu’une description de ce concept peut être trouvée sur le Web. Par exemple, en utilisant l’URI DBpedia http://dbpedia.org/page/Doom pour identifier le jeu vidéo Doom vous obtenez une description détaillée du jeu, y compris les résumés en 10 langues différentes et de diverses classifications.
2. Les URI sont déjà liés à des URI d’autres sources de données. Par exemple, vous pouvez naviguer à partir de l’URI DBpedia http://dbpedia.org/resource/Berlin vers des données sur Berlin fournies par Geonames et Eurostat. Ainsi, en utilisant des URI de ces ensembles de données, vous reliez vos données grâce à un réseau de sources de données dense et en croissance rapide .

Une liste plus étendue d’ensembles de données avec des URI déréférençables est maintenue par le projet de la communauté Linking Open Data dans le wiki ESW.

Dans les profils FOAF de Tim Berners-Lee et Ivan Herman, vous trouverez de bons exemples sur la façon dont des termes de différents vocabulaires bien connus sont mélangés au sein d’un seul document et sur la manière de réutiliser des URI existants.

4.2 – Comment définir les conditions ?

Lorsque vous ne pouvez pas trouver de bons vocabulaires existants qui couvrent toutes les classes et les propriétés dont vous avez besoin, vous devez définir vos propres termes. La définition de nouveaux termes n’est pas difficile. Les classes et les propriétés RDF sont elles-mêmes des ressources identifiées par des URI et publiées sur le Web. Donc tout ce que nous avons dit à propos de la publication des données liées s’applique à elles aussi.

Vous pouvez définir des vocabulaires RDF en utilisant le langage RDF Vocabulary Description Language 1.0: RDF Schema ou le langage Web Ontology Language (OWL). Pour les introductions aux RDFS, voir la section sur le vocabulaire de documentation dans le tutorial SWAP, et la section très détaillée RDF Schema du Primer RDF. OWL est introduit dans OWL Overview.

Nous donnons ici quelques conseils pour ceux qui sont familiers avec ces langues :

1. Ne définissez pas un nouveau vocabulaire à partir de zéro, mais complétez les vocabulaires existants avec des termes supplémentaires (dans votre propre espace de noms) pour représenter vos données selon vos besoins.
2. Définissez pour les humains et pour les machines. Au stade actuel du développement du Web de données, il y a plus de gens que de machines qui viennent visiter votre site, même si le Web de données est a priori plus destiné aux machines. N’oubliez pas d’ajouter de la prose, par exemple rdfs:comment pour chaque terme inventé. Et fournissez toujours une étiquette pour chaque terme qui utilise la propriété rdfs:label.
3. Faites des termes d’URI dereferenceables. Il est essentiel que les termes d’URI soient déréférenceables afin que les clients puissent rechercher la définition d’un terme. Suivez donc les recettes du W3C sur les meilleures pratiques de la publication de vocabulaires RDF pour faire des termes d’URI déréférenceables.
4. Faites usage de termes d’autres personnes. L’utilisation de termes d’autres personnes, ou de mapping sur eux, contribue à promouvoir le niveau d’échange de données sur le Web de données, de la même manière que les liens hypertextes construisent le Web de documents. Des propriétés communes pour fournir des telles applications sont rdfs:subClassOf ou rdfs:subPropertyOf.
5. Faites état explicitement de toutes les informations importantes. Par exemple, indiquez explicitement tous les ranges [c’est le terme anglais] et tous les domaines. N’oubliez pas : les humains peuvent souvent faire des conjectures, mais pas les machines. Ne négligez pas d’informations importantes !
6. Ne créez pas de termes trop limités, ou fragiles ; laissez une certaine souplesse pour permettre les évolutions. Par exemple, si vous utilisez des fonctionnalités OWL complètes pour définir votre vocabulaire, vous pourrez avoir des choses qui conduisent à des conséquences non désirées et à des incohérences quand quelqu’un d’autre utilisera vos références dans une définition de vocabulaire différent. Ainsi, à moins que vous sachiez exactement ce que vous faites, utilisez RDF-Schema pour définir des vocabulaires.

L’exemple suivant contient la définition d’une classe et une propriété en suivant les règles ci-dessus. L’exemple utilise la syntaxe de Turtle. Les déclarations d’espace de noms ont été omises.

# Définition de la classe « Lover »

<http://sites.wiwiss.fu-berlin.de/suhl/bizer/pub/LoveVocabulary#Lover>
rdf:type rdfs:Class ;
rdfs:label « Lover »@en ;
rdfs:label « Liebender »@de ;
rdfs:comment « A person who loves somebody. »@en ;
rdfs:comment « Eine Person die Jemanden liebt. »@de ;
rdfs:subClassOf foaf:Person .

# Définition de la propriété « aime »

<http://sites.wiwiss.fu-berlin.de/suhl/bizer/pub/LoveVocabublary#loves>
rdf:type rdf:Property ;
rdfs:label « loves »@en ;
rdfs:label « liebt »@de ;
rdfs:comment « Relation between a lover and a loved person. »@en ;
rdfs:comment « Beziehung zwischen einem Liebenden und einer geliebten Person. »@de ;
rdfs:subPropertyOf foaf:knows ;
rdfs:domain <http://sites.wiwiss.fu-berlin.de/suhl/bizer/pub/LoveVocabulary#Lover> ;
rdfs:range foaf:Person .

Notez que les termes sont définis dans un espace qui est contrôlée par Chris Bizer et qu’elles sont liées au vocabulaire FOAF utilisant des liens rdfs:subPropertyOf et rdfs:subClassOf liens.