I. Un bref historique▲
Retour au seizième siècle. Début de l'imprimerie. Les livres commençaient à se répandre. Les érudits avaient de nouvelles sources.
Cependant, tout n'allait pas forcément pour le mieux dans le meilleur des mondes : outre le fait que tout le monde n'avait pas accès à la connaissance, il fallait encore savoir... ce qui était disponible.
1595. Leiden, Pays-Bas. Nomenclator.
Le premier catalogue imprimé.
Enfin, on pouvait savoir à Berlin ce que contenait une bibliothèque. Sans s'y trouver physiquement. Sans envoyer de demande par courrier postal.
D'autres bibliothèques ont suivi le mouvement, bien évidemment, pour ne pas se retrouver entièrement dépassées. D'autres catalogues imprimés parurent, furent distribués un peu partout dans le monde. On pouvait alors comparer plusieurs bibliothèques : vaut-il mieux aller à Sodome ou à Gomorrhe pour se documenter sur les découvertes de Christophe Colomb ?
Le Web des données se situe dans la même position : beaucoup de données sont disponibles, mais on ne sait pas qu'elles existent. Pour pallier ce problème, on a créé divers systèmes qui vont être décrits dans cet article. On va chercher à déclarer au monde entier qu'une source de données existe (généralement, un SPARQL end point(1), cela peut aussi bien être un fichier de triplets RDF sérialisés d'une manière ou d'une autre (2)), ce qu'elle contient (quels sont les sujets des données disponibles). Tout ce qu'il faut est un vocabulaire commun pour décrire ces sources de données.
II. L'expérience acquise du Web des documents▲
Le Web tel qu'actuellement connu, le Web des documents, permet lui aussi de faire des recherches, de trouver de l'information, grâce aux moteurs de recherche. Qu'est-ce qui a bien fonctionné dans ce système ? Quelles pistes intéressantes seraient à reprendre pour le Web des données ?
Il n'y a pas une seule et unique source de contenu. Chacun publie son contenu dans son coin, parfois sans se soucier qu'il soit facilement trouvable par d'autres. Il n'est pas obligatoire de présenter chaque nouvelle page, chaque modification à un organisme central. Par contre, il y a plusieurs moteurs de recherche, chacun tente de présenter son site Web de telle sorte qu'il soit bien indexé par ces moteurs, toute une industrie parallèle s'est développée sur ce sujet précis.
Cette solution a pu se développer à l'échelle actuelle du Web. Le créateur de contenu « annote » ses créations pour que les moteurs les retrouvent, les indexent, en prennent grand soin. Les moteurs, quant à eux, effectuent la partie la plus détestable du travail : récupérer ce peu d'informations, de descriptions, les digérer, les stocker et les régurgiter sous une forme acceptable lorsque cela est demandé.
Pour faciliter ce travail d'indexation du contenu, les plus grands moteurs de recherche se sont rassemblés et ont décidé d'un format commun, les sitemaps, pour que les webmasters puissent leur communiquer l'ensemble des pages disponibles sur un site, avec quelques autres métadonnées supplémentaires, leur facilitant de facto un peu le travail.
Pour le Web des données, on veut pouvoir agir de la même manière : en ayant une requête à formuler, on recherche l'ensemble de données qui est susceptible de convenir (on effectue une recherche sur un moteur de recherche sur certains mots-clés pour trouver des pages au contenu intéressant), on exploite ces informations (on lit l'article déniché).
Cependant, tout n'est pas si rose : alors que le Web des documents était visité par des êtres humains, capables de beaucoup de raisonnement, le Web des données est prévu pour être exploité par des machines, aux capacités cognitives plus faibles. Il ne suffit donc plus d'effectuer des recherches dans l'à -peu-près qui caractérise les moteurs actuels, il faut être capable de plus de précision, il faut que les ensembles de données soient décrits de manière plus fine. Les publicateurs doivent donc promouvoir leurs données aussi précisément que possible, avec des mots adaptés.
Bien que cette introduction puisse sembler accessible à tout public, la suite l'est nettement moins, il est nécessaire d'avoir bien compris les concepts de base du Web sémantique : triplet RDF, ontologie et vocabulaire, requête SPARQL, RDFa, etc. Si ces mots vous effraient, voir Introduction au Web sémantique ou d'autres cours plus avancés. Les triplets RDF seront représentés en Turtle, donc compatible Notation3, les requêtes à l'aide de SPARQL.
III. Le vocabulaire VoID▲
Vocabulary of Interlinked Datasets.
Il s'agit de décrire le contenu des ensembles de données liées : cet ensemble contient 2042 liens de type foaf:depict vers tel autre ensemble, contenant principalement des données sur les avions de chasse. Tout ceci est décrit en RDF, ce qui permet d'effectuer des requêtes SPARQL sur une base pour chercher les meilleures sources de données pour son utilisation.
On a donc la première pièce du puzzle : on a l'équivalent d'un moteur de recherche, dont les données sont spécifiées précisément, on peut effectuer des requêtes, on ne se base pas sur des recherches en texte plein ou avec des approximations.
Ce vocabulaire est principalement constitué de deux classes : une pour décrire les ensembles de données (void:Dataset), l'autre pour indiquer les liens entre ces ensembles (void:Linkset).
Un void:Dataset est une collection de données publiées par un seul fournisseur, disponibles en RDF et accessibles (soit par des URI déréférençables, soit par un SPARQL endpoint, soit par une autre méthode).
Pour chaque lien, on utilise la classe void:Linkset, sous-classe de void:Dataset. Un tel triplet est toujours constitué d'un objet (une ressource de l'ensemble à décrire) et d'un sujet (une ressource d'un autre ensemble lié).
Par exemple, on peut décrire les relations entre DBpedia et la base de données bibliographiques DBLP :
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix void: <http://rdfs.org/ns/void#> .
:DBpedia rdf:type void:Dataset ;
foaf:homepage <http://dbpedia.org/> .
:DBLP rdf:type void:Dataset ;
foaf:homepage <http://www4.wiwiss.fu-berlin.de/dblp/all> ;
dcterms:subject <http://dbpedia.org/resource/Computer_science> ;
dcterms:subject <http://dbpedia.org/resource/Journal> ;
dcterms:subject <http://dbpedia.org/resource/Proceedings> .
:DBpedia void:subset :DBpedia2DBLP .
:DBpedia2DBLP rdf:type void:Linkset ;
void:target :DBpedia ;
void:target :DBLP .En insérant ces triplets ainsi que bien d'autres décrivant des relations entre d'autres ensembles de données, on peut imaginer effectuer une requête pour déterminer quel ensemble regarder pour des données sur n'importe quel sujet :
SELECT DISTINCT ?dataset
WHERE {
?dataset a void:Dataset .
?dataset dcterms:subject <http://dbpedia.org/resource/Journal> .
}IV. Écrire un fichier VoID▲
On va ici décrire la majorité des possibilités de ce vocabulaire pour un ensemble de données en développant un exemple basé sur DBpedia, mais avec beaucoup de parties fictives ne correspondant pas forcément à la réalité.
IV-A. Description de l'ensemble de données▲
On commence par spécifier que l'on a affaire à un ensemble de données :
:DBpedia a void:Dataset .IV-A-1. Informations de base▲
Cependant, cela n'apporte pas beaucoup d'informations. En réalité, beaucoup trop peu pour que l'on puisse en retirer quelque chose d'utile. On commence donc par préciser la page d'accueil (foaf:homepage), ainsi que d'autres pages utiles (foaf:page) :
:DBpedia a void:Dataset ;
foaf:homepage <http://dbpedia.org/> ;
foaf:page <http://ckan.net/package/dbpedia> ;
foaf:page <http://dbpedia.org/Downloads> ;
.IV-A-2. Informations utiles▲
On peut ensuite ajouter quelques autres métadonnées : le titre (dcterms:title), une description (dcterms:description), les créateurs (dcterms:creator), éditeurs (dcterms:publisher) et contributeurs (dcterms:contributor), une description RDF de la source des données (dcterms:source), ainsi que les dates de création (dcterms:created), publication (dcterms:issued) et dernière modification (dcterms:modified).
Il est aussi probablement utile de fournir des informations de contact pour les créateurs, éditeurs et contributeurs à l'aide de foaf:mbox. On peut aussi préciser s'il s'agit d'une personne (foaf:Person) ou d'une organisation (foaf:Organization).
:DBpedia a void:Dataset ;
dcterms:title "DBPedia" ;
dcterms:description "RDF data extracted from Wikipedia" ;
dcterms:contributor :FU_Berlin ;
dcterms:publisher :Alice ;
dcterms:source <http://dbpedia.org/resource/Wikipedia> ;
dcterms:modified "2011-08-14"^^xsd:date ;
.
:FU_Berlin a foaf:Organization ;
rdfs:label "Freie Universität Berlin" ;
foaf:homepage <http://www.fu-berlin.de/> ;
.
:Alice a foaf:Person ;
rdfs:label "Alice" ;
foaf:mbox <mailto:alice@example.com> ;
.IV-A-3. Licence▲
La licence est également un élément très important (3) que l'on peut spécifier avec dcterms:license. Il est également possible à l'éditeur de renoncer à une série de droits sur ces données pour en favoriser l'utilisation, on utilise alors waiver:norms.
:DBpedia a void:Dataset ;
dcterms:title "DBPedia" ;
dcterms:description "RDF data extracted from Wikipedia" ;
dcterms:contributor :FU_Berlin ;
dcterms:publisher :Alice ;
dcterms:source <http://dbpedia.org/resource/Wikipedia> ;
dcterms:modified "2011-08-14"^^xsd:date ;
dcterms:license <http://www.opendatacommons.org/odc-public-domain-dedication-and-licence/> ;
wv:norms <http://www.opendatacommons.org/norms/odc-by-sa/> ;
wv:waiver """To the extent possible under law, The Example Organisation has waived all
copyright and related or neighboring rights to The Example Dataset.""" ;
.
:FU_Berlin a foaf:Organization ;
rdfs:label "Freie Universität Berlin" ;
foaf:homepage <http://www.fu-berlin.de/> ;
.
:Alice a foaf:Person ;
rdfs:label "Alice" ;
foaf:mbox <mailto:alice@example.com> ;
.IV-A-4. Sujets▲
Toute la substance de ce vocabulaire, par contre, tient dans les sujets que traite l'ensemble, ce sans quoi le reste n'a pas grande utilité. On utilise le prédicat dcterms:subject avec un sujet, de préférence une URI de ressource sur DBpedia (afin d'uniformiser les sujets et de faciliter les recherches).
:DBpedia a void:Dataset ;
dcterms:title "DBPedia" ;
dcterms:description "RDF data extracted from Wikipedia" ;
dcterms:contributor :FU_Berlin ;
dcterms:publisher :Alice ;
dcterms:source <http://dbpedia.org/resource/Wikipedia> ;
dcterms:modified "2011-08-14"^^xsd:date ;
dcterms:license <http://www.opendatacommons.org/odc-public-domain-dedication-and-licence/> ;
wv:norms <http://www.opendatacommons.org/norms/odc-by-sa/> ;
wv:waiver """To the extent possible under law, The Example Organisation has waived all
copyright and related or neighboring rights to The Example Dataset.""" ;
dcterms:subject <http://dbpedia.org/resource/Encyclopedia> ;
.
:FU_Berlin a foaf:Organization ;
rdfs:label "Freie Universität Berlin" ;
foaf:homepage <http://www.fu-berlin.de/> ;
.
:Alice a foaf:Person ;
rdfs:label "Alice" ;
foaf:mbox <mailto:alice@example.com> ;
.DBpedia ne contient cependant pas des sujets pour tous les ensembles de données, particulièrement s'il concerne la génétique ou un autre sujet peu répandu. Dans ce cas, on utilise des URI largement répandues dans les communautés concernées.
IV-A-5. Fonctionnalités techniques▲
On peut spécifier une série de fonctionnalités techniques, comme les possibilités de sérialisation des triplets RDF, à l'aide de void:feature. Au besoin, on peut définir ses propres fonctionnalités.
:DBpedia a void:Dataset ;
dcterms:title "DBPedia" ;
dcterms:description "RDF data extracted from Wikipedia" ;
dcterms:contributor :FU_Berlin ;
dcterms:publisher :Alice ;
dcterms:source <http://dbpedia.org/resource/Wikipedia> ;
dcterms:modified "2011-08-14"^^xsd:date ;
dcterms:license <http://www.opendatacommons.org/odc-public-domain-dedication-and-licence/> ;
wv:norms <http://www.opendatacommons.org/norms/odc-by-sa/> ;
wv:waiver """To the extent possible under law, The Example Organisation has waived all
copyright and related or neighboring rights to The Example Dataset.""" ;
dcterms:subject <http://dbpedia.org/resource/Encyclopedia> ;
void:feature <http://www.w3.org/ns/formats/N3> ;
void:feature <http://www.w3.org/ns/formats/N-Triples> ;
void:feature <http://www.w3.org/ns/formats/RDF_XML> ;
void:feature <http://www.w3.org/ns/formats/RDFa> ;
void:feature <http://www.w3.org/ns/formats/Turtle> ;
void:feature <http://www.w3.org/ns/formats/HTTPCachingETags> ;
.
:FU_Berlin a foaf:Organization ;
rdfs:label "Freie Universität Berlin" ;
foaf:homepage <http://www.fu-berlin.de/> ;
.
:Alice a foaf:Person ;
rdfs:label "Alice" ;
foaf:mbox <mailto:alice@example.com> ;
.
:HTTPCachingETags a void:TechnicalFeature;
rdfs:label "HTTP ETag support" ;
rdfs:comment "The dataset supports HTTP caching using ETags" ;
rdfs:seeAlso <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#> ;
.IV-A-6. Sous-ensembles▲
On peut simplement définir un ensemble comme plusieurs sous-ensembles, on peut alors définir des propriétés ne se rapportant qu'à un seul sous-ensemble et pas au reste.
:DBpedia a void:Dataset;
void:subset :DBpedia_shortabstracts;
void:subset :DBpedia_infoboxes;
.
:DBpedia_shortabstracts a void:Dataset;
dcterms:title "DBpedia Short Abstracts";
dcterms:description "Short Abstracts (max. 500 chars long) of Wikipedia Articles";
void:dataDump <http://downloads.dbpedia.org/3.3/en/shortabstract_en.nt.bz2>;
.
:DBpedia_infoboxes a void:Dataset;
dcterms:title "DBpedia Infoboxes";
dcterms:description "Information that has been extracted from Wikipedia infoboxes.";
void:dataDump <http://downloads.dbpedia.org/3.3/en/infobox_en.nt.bz2>;
.void:dataDump sera introduit très prochainement, il s'agit de lier un fichier contenant tous les triplets de l'ensemble sérialisés.
IV-A-7. Statistiques▲
On peut définir un certain nombre de statistiques pour un ensemble de données : le nombre de triplets (void:triples), d'entités (4) (void:entities), de classes (void:classes), de propriétés (void:properties), de sujets distincts (void:distinctSubjects), d'objets distincts (void:distinctObjects) et de documents (5) (void:documents).
:DBpedia a void:Dataset ;
dcterms:title "DBPedia" ;
dcterms:description "RDF data extracted from Wikipedia" ;
dcterms:contributor :FU_Berlin ;
dcterms:publisher :Alice ;
dcterms:source <http://dbpedia.org/resource/Wikipedia> ;
dcterms:modified "2011-08-14"^^xsd:date ;
dcterms:license <http://www.opendatacommons.org/odc-public-domain-dedication-and-licence/> ;
wv:norms <http://www.opendatacommons.org/norms/odc-by-sa/> ;
wv:waiver """To the extent possible under law, The Example Organisation has waived all
copyright and related or neighboring rights to The Example Dataset.""" ;
dcterms:subject <http://dbpedia.org/resource/Encyclopedia> ;
void:feature <http://www.w3.org/ns/formats/N3> ;
void:feature <http://www.w3.org/ns/formats/N-Triples> ;
void:feature <http://www.w3.org/ns/formats/RDF_XML> ;
void:feature <http://www.w3.org/ns/formats/RDFa> ;
void:feature <http://www.w3.org/ns/formats/Turtle> ;
void:feature <http://www.w3.org/ns/formats/HTTPCachingETags> ;
void:triples 1000000000;
void:entities 4200000;
.
:FU_Berlin a foaf:Organization ;
rdfs:label "Freie Universität Berlin" ;
foaf:homepage <http://www.fu-berlin.de/> ;
.
:Alice a foaf:Person ;
rdfs:label "Alice" ;
foaf:mbox <mailto:alice@example.com> ;
.
:HTTPCachingETags a void:TechnicalFeature;
rdfs:label "HTTP ETag support" ;
rdfs:comment "The dataset supports HTTP caching using ETags" ;
rdfs:seeAlso <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#> ;
.Ces statistiques permettent de quantifier la qualité d'un ensemble de données, notamment en regardant le nombre de triplets disponibles en moyenne pour chaque entité, le nombre de sujets et d'objets distincts montrant la diversité de l'ensemble.
IV-B. Accès aux triplets▲
Jusqu'à présent, on n'a pas donné de manière d'accéder aux triplets. On doit donc effectuer une requête, aller sur le site Web... puis chercher l'accès aux triplets. Rien de vraiment automatisable. Sauf si on indique précisément comment dénicher ces triplets !
On simplifiera fortement l'exemple précédent, le réduisant à un nombre de triplets proche de zéro.
IV-B-1. SPARQL endpoint▲
On peut indiquer un habituel SPARQL endpoint :
:DBpedia a void:Dataset ;
void:sparqlEndpoint <http://dbpedia.org/sparql>;
.IV-B-2. Fichiers RDF▲
Il ne serait pas étonnant d'aussi trouver des fichiers RDF contenant l'ensemble des triplets disponibles dans la base à un moment donné. On peut préciser plusieurs liens vers des fichiers contenant des triplets sérialisés dans un format habituel (sans qu'il y ait moyen de le préciser explicitement, on peut se baser sur les fonctionnalités techniques (6)), possiblement compresser. On doit lier directement les fichiers, pas une page permettant de les télécharger.
:DBpedia a void:Dataset ;
void:sparqlEndpoint <http://dbpedia.org/sparql>;
void:dataDump <http://downloads.dbpedia.org/3.6/en/article_categories_en.nt.bz2> ;
void:dataDump <http://downloads.dbpedia.org/3.6/el/disambiguations_el.nq.bz2> ;
.IV-B-3. OpenSearch▲
OpenSearch est un format de document permettant de décrire un moteur de recherche (notamment, les navigateurs Web qui le supportent proposent d'ajouter un moteur de recherche disposant d'un fichier OpenSearch à la liste des moteurs de recherche disponibles dans les barres d'outils appropriées). Il s'agit ici d'une recherche textuelle classique.
:DBpedia a void:Dataset ;
void:sparqlEndpoint <http://dbpedia.org/sparql>;
void:dataDump <http://downloads.dbpedia.org/3.6/en/article_categories_en.nt.bz2> ;
void:dataDump <http://downloads.dbpedia.org/3.6/el/disambiguations_el.nq.bz2> ;
void:openSearchDescription <http://www.sindice.com/opensearch.xml> ;
.IV-B-4. URI de recherche▲
On dispose parfois aussi d'URI permettant d'effectuer des recherches, donnant la description RDF de l'entité passée en paramètre. Par exemple, on peut effectuer une recherche sur Cat via Sindice à l'URI http://api.sindice.com/v2/search?qt=term&q=Cat. On décrira cette manière de rechercher comme suit :
:DBpedia a void:Dataset ;
void:sparqlEndpoint <http://dbpedia.org/sparql>;
void:dataDump <http://downloads.dbpedia.org/3.6/en/article_categories_en.nt.bz2> ;
void:dataDump <http://downloads.dbpedia.org/3.6/el/disambiguations_el.nq.bz2> ;
void:openSearchDescription <http://www.sindice.com/opensearch.xml> ;
void:uriLookupEndpoint <http://api.sindice.com/v2/search?qt=term&q=> ;
.IV-C. Description des liens▲
On crée simplement un lien entre deux ensembles décrits dans le même fichier comme ceci :
:DBpedia_Geonames a void:Linkset;
void:target :DBpedia ;
void:target :Geonames ;
.On ne peut présenter ainsi que deux ensembles à la fois, chacun avec une propriété void:target.
IV-C-1. Statistiques▲
On peut définir le nombre de triplets concernés par ce lien (ou toute autre statistique possible, étant donné que la classe void:linkset dérive de void:Dataset). Cela est néanmoins plus utile lorsque l'on précise le prédicat sur lequel porte le lien.
:DBpedia_Geonames a void:Linkset;
void:target :DBpedia ;
void:target :Geonames ;
void:triples 242000 ;
.IV-C-2. Prédicat visé par le lien▲
La propriété void:linkPredicate sert à préciser la nature du lien entre les deux ensembles.
:DBpedia_Geonames a void:Linkset;
void:target :DBpedia ;
void:target :Geonames ;
void:linkPredicate owl:sameAs ;
.IV-D. Utilisation pratique du fichier▲
C'est bien de créer toutes ces données, encore faut-il qu'elles soient exploitables par des moteurs de recherche tels que Sindice. Tout d'abord, il faut mettre ce fichier à proximité de l'ensemble de données. Plusieurs options : un fichier void.ttl au format Turtle à la racine du site, servir les formats HTML et RDF pour l'URI racine du site (voir Cool URIs) ou intégrer le tout dans la page grâce à RDFa.
Il n'est pas recommandé d'intégrer ces données à un fichier de triplets RDF contenant toutes les données. Par contre, on peut ajouter un triplet pointant vers cette description :
<document.rdf> void:inDataset <void.ttl#MyDataset> .Pour soumission à Sindice, il faut se rendre dans l'onglet Submit du site et ajouter l'URI du fichier VoID dans la grande boîte. (7)
Sur le VoID store de RKB, la procédure est fortement similaire, ainsi que sur le VoID browser de Talis ou Ping the Semantic Web. Comme sur le Web des documents, cela ne fait pas de mal de soumettre ce fichier à divers endroits pour maximiser sa visibilité.
V. Les sitemaps▲
Deuxième brique identifiée dans l'introduction, les sitemaps, des documents listant toutes les pages d'un site avec d'autres informations potentiellement utiles au moteur de recherche.
Au contraire, sur le Web des données, comme on peut effectuer des requêtes SPARQL pour savoir tout ce qui est disponible, il n'est pas si utile de lister quelque part tout le contenu ; par contre, préciser quelles sont les méthodes possibles pour récupérer les triplets peut être utile : si on veut effectuer énormément de requêtes sur un ensemble, autant télécharger les triplets le composant et effectuer le traitement en local, pour éviter de surcharger le serveur distant. A contrario, pour deux ou trois requêtes, autant bénéficier du SPARQL endpoint ou de l'accès par URI. (8)
Mais peut-on le faire ? Comment peut-on s'assurer qu'on aura exactement les mêmes données d'un côté ou de l'autre ? C'est le but des sitemaps sémantiques.
V-A. Prévenir de l'existence d'un sitemap▲
Tout d'abord, il faut que l'on puisse trouver ce sitemap en visitant le site. On peut l'indiquer grâce au fichier robots.txt.
Sitemap: http://www.site.com/sitemap.xmlV-B. Écrire le sitemap▲
Il ne s'agit que d'une extension du format de sitemaps déjà largement admis. Si le site en dispose déjà , il suffira d'y ajouter quelques lignes. On va partir d'un exemple complet à détailler.
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:sc="http://sw.deri.org/2007/07/sitemapextension/scschema.xsd">
<sc:dataset>
<sc:datasetLabel>Example Corp. Product Catalog</sc:datasetLabel>
<sc:datasetURI>http://example.com/catalog.rdf#catalog</sc:datasetURI>
<sc:sampleURI>http://example.com/products/widgets/X42</sc:sampleURI>
<sc:sampleURI>http://example.com/products/categories/all</sc:sampleURI>
<sc:sparqlEndpointLocation slicing="subject-object">http://example.com/sparql</sc:sparqlEndpointLocation>
<sc:dataDumpLocation>http://example.com/data/catalogdump.rdf.gz</sc:dataDumpLocation>
<sc:dataDumpLocation>http://example.org/data/catalog_archive.rdf.gz</sc:dataDumpLocation>
<sc:dataDumpLocation>http://example.org/data/product_categories.rdf.gz</sc:dataDumpLocation>
<changefreq>weekly</changefreq>
</sc:dataset>
</urlset>V-B-1. Ensemble de données▲
<sc:dataset>
<!-- ... -->
</sc:dataset>On définit d'abord un ensemble de données. Un sitemap peut définir plusieurs ensembles de données.
V-B-2. Informations générales▲
<sc:datasetLabel>Example Corp. Product Catalog</sc:datasetLabel>
<sc:datasetURI>http://example.com/catalog.rdf#catalog</sc:datasetURI>Ces deux éléments sont optionnels et fournissent des métadonnées sur l'ensemble de données : respectivement, le nom et l'URI. Généralement, la résolution de l'URI donne plus d'informations sur l'ensemble, possiblement en RDF, mais ce n'est pas requis.
V-B-3. URI d'exemples▲
<sc:sampleURI>http://example.com/products/widgets/X42</sc:sampleURI>
<sc:sampleURI>http://example.com/products/categories/all</sc:sampleURI>Ces URI optionnelles peuvent pointer vers des échantillons représentatifs de l'ensemble. Elles servent comme point de base pour une exploration humaine de l'ensemble.
V-B-4. Triplets▲
<sc:sparqlEndpointLocation slicing="subject-object">http://example.com/sparql</sc:sparqlEndpointLocation>
<sc:dataDumpLocation>http://example.com/data/catalogdump.rdf.gz</sc:dataDumpLocation>
<sc:dataDumpLocation>http://example.org/data/catalog_archive.rdf.gz</sc:dataDumpLocation>
<sc:dataDumpLocation>http://example.org/data/product_categories.rdf.gz</sc:dataDumpLocation>Le point central (obligatoire), les sources de données, l'objectif même des sitemaps. On a défini ici un SPARQL endpoint (il peut y en avoir au plus un par ensemble). On a ajouté quelques fichiers RDF, dont l'union est dite être l'ensemble des données. Cette union doit d'ailleurs être disponible par le biais du SPARQL endpoint.
V-B-5. Modifications▲
<changefreq>weekly</changefreq>On spécifie ici la fréquence de mise à jour de l'ensemble, cette balise optionnelle est héritée du protocole sitemap. On a aussi la balise <lastmod> pour indiquer la dernière mise à jour (au format W3C : AAAA-MM-DD ou AAAA-MM-DDTHH:MM:SS+HH:MM.
V-C. Référencer le sitemap sur Sindice▲
Mettre à disposition le sitemap par robots.txt ne sera pas suffisant pour que les moteurs de recherche y aient accès, tout comme pour le Web des documents.
On va ici le référencer sur Sindice, principal moteur de recherche pour le Web sémantique. On retourne à l'onglet Submit, mais pour remplir le deuxième formulaire : il suffit d'y préciser l'URL du sitemap puis de cliquer sur le bouton. C'est simple et pourtant le sitemap est envoyé et sera référencé.
Il faut aussi avoir envoyé son fichier VoID pour être référençable sur Sindice.
VI. Conclusions▲
Référencer ses données dans le monde du Web sémantique n'est pas chose compliquée pour qui a déjà une petite expérience des technologies mises en place. On peut voir d'ailleurs qu'il s'agit d'une adaptation des solutions déjà trouvées pour le Web des documents : pourquoi réinventer la roue ? Surtout que l'on dispose déjà d'outils qui fonctionnent très bien (les sitemaps, mais aussi les SPARQL endpoints, Turtle et bien d'autres) !
VII. Remerciements▲
Merci à Julien Plu et Dominique Kirchhofer pour leur relecture et conseils ! Merci à Claude Leloup et ram-0000 pour leur relecture orthographique !