J'ai déjà fait allusion à plusieurs reprises au vocabulaire RDF, SKOS (Simple knowledge organisation system) sur ce blog. Développé sous l'égide du W3C, il a pour but la modélisation et la mise à disposition selon le principe de RDF des thésaurus, taxonomies, glossaires et autres vocabulaires contrôlés. La mise en ligne des thésaurus existants au format RDF est fondamental dans le déploiement du Web sémantique, car cela permet d'associer à chaque concept une URI et ainsi de pouvoir y faire référence dans d'autres fichiers RDF.
Par exemple, si je décris une page Web en Dublin Core, je vais utiliser la propriété 'dc:subject' pour associer un mot-clef à cette page. Si ma page a pour sujet l'hypertexte, mon assertion peut avoir pour objet le mot-clef « lien » : <htttp://mapageweb.fr> <http://purl.org/dc/elements/1.1/subject> « lien ». Dans ce cas, le sujet est une chaîne de caractère sur laquelle le système informatique n'a aucune information. En revanche, comme il existe sur le site du W3C un glossaire expliquant les différents termes du domaine de l'hypertexte, je peux directement lier ma propriété au concept de « link » définit dans ce thésaurus. Dans ce cas, ce n'est plus une chaîne de caractère qui est l'objet de mon assertion, mais le concept en lui-même et le système informatique pourra récupérer les informations associées au concept dans le fichier SKOS mis à disposition au W3C. Mon assertion sera alors <http://mapageweb.fr> <http://purl.org/dc/elements/1.1/subject> <http://www.w3.org/2003/03/glossary-project/data/glossaries/hypertext-terms#link>.
Les conséquences de la différence entre une simple chaîne de caractère et un lien vers un concept défini dans un fichier SKOS sont très importantes. A notre page Web, nous avons associé la propriété 'dc:subject' qui a pour objet un lien vers le concept 'link' défini dans le glossaire du W3C. Or, dans ce glossaire, le concept de lien est relié de façon hiérarchique avec le concept 'hypertext' et de façon transversale avec le concept 'anchor' (en réalité, ce n'est pas le cas, mais imaginons ;-) ). Si je recherche dans un moteur capable de comprendre le SKOS la chaîne de caractère 'hypertext', alors le moteur sera capable de trouver ma page Web, même si je n'ai pas utilisé le mot hypertext dans les métadonnées ou dans le corps de ma page Web, car, selon mon SKOS, 'hypertext' est lié à 'link'. Cela ouvre en fait la voie à une véritable recherche sémantique. Si vous voulez en savoir plus sur SKOS, je vous renvoie au billet de Sylvie Dalbin et à ce diaporama qui fait le tour de la question et revenons en maintenant à la folksonomie.
Comme je le disais dans mon précédent billet, on peut assimiler une liste de tags à un vocabulaire défini par l'utilisateur. On peut donc exprimer facilement cette liste avec le vocabulaire SKOS. J'ai mis au point un petit script qui permet de récupérer les tags d'un utilisateur dans Flick'r et de les exprimer en SKOS. Vous indiquez simplement votre nom d'utilisateur dans Flick'r, le script récupère votre liste de tags et grâce à la classe RAP et au Web services de Flick'r, vous obtenez votre fichier SKOS. Mais, dans ce cas, il n'existe aucune relation entre les différents tags. Pour autant, on va pouvoir travailler à partir de ce fichier et construire un véritable thésaurus.
Trois types de relations peuvent être exprimés en SKOS :
une hiérarchie entre les tags avec les propriétés 'skos:narrower' (descendant), par exemple, la France possède un lien descendant avec Paris et 'skos:broader' (ascendant), la propriété inverse, par exemple Paris possède un lien ascendant avec la France ;
Une relation entre les tags avec la propriété 'skos:related', par exemple la Seine et Paris sont deux concepts qui peuvent être liés ;
des étiquettes alternatives à mon tag, par exemple, Parigi est une étiquette alternative à Paris.
C'est ce que j'ai fait avec certains de mes tags de Flick'r et j'obtiens ce fichier SKOS. Dans ce cas, j'ai écrit directement ce fichier en RDF, mais il est assez simple de construire une interface pour le faire, à l'image du logiciel trematres. A partir de ce fichier SKOS, j'ai construit une petite interface pour visualiser mon thésaurus avec une feuille de style XSL (j'aurais pu obtenir la même chose avec SPARQL, mais j'ai préféré faire simple). Cette interface permet de montrer la hiérarchisation de mes tags telle qu'elle est indiquée dans le fichier SKOS. Si vous cliquez sur un des tags, vous visualiserez non seulement les photos qui ont ce tag, mais aussi les photos qui possèdent un des tags inférieurs à celui-ci, même s'il ne possède pas le tag père. Ainsi, si vous cliquez sur Paris, vous obtiendrez les photos des différents arrondissement de la capitale, alors que mes photos n'utilisent pas le tag Paris. A partir de ce modèle, il est facile de créer des interfaces de recherche avec les tags liés ou entre les différents utilisateurs qui utilisent des tags différents pour un même lieu/concept/chose. CQFD ;-)
Grâce à SKOS, il est tout à fait possible de réaliser ce que Souslapoussière exprimait dans son commentaire sur mon précédent billet. Pour cela, il faut créer son fichier SKOS et le mettre à disposition sur le Web. Les applications tels que les blogs, Flick'r, del.icio.us et autres devraient être capables de récupérer ce fichier et de vous proposer dans leurs interfaces les différents concepts listés dans votre fichier SKOS. Lorsqu'elles seront capables de le faire et il me semble avoir démontré que cela n'était pas extrêmement compliqué, alors là, oui, on pourra dire qu'on est entré dans une nouvelle ère technologique du Web, un vrai Web 2.0, un Web qui utilise les technologies du Web sémantique.
Commentaires
Lier folksonomie et ontologie, je ne comprends pas bien... Ce n'est tout simplement pas la même chose. Si tu commences à vouloir relier les différents tags d'une folksonomie, alors cela devient une ontologie ou du moins une taxonomie, ou un thésaurus. Tu devrais reprendre l'ontology spectrum, c'est très éclairant sur la différence entre ces différentes façons d'organiser l'information.
Got,
Je me permets de te signaler une petite erreur RDF dans ton billet.
Le triplet est faux car la propriété http://purl.org/dc/elements/1.1/subject n'accepte que des valeurs littérales, pas des URI.
Tu l'as sûrement confondue avec sa petite sœur : http://purl.org/dc/terms/subject
Il est vrai que les deux vocabulaires Dublin Core sont sources de confusion, c'est pour ça que j'ai écrit un billet expliquant ce qui les distinguent : http://pierre.dureau.me/billet/2010-08-13-de-vieilles-connaissances-2
N'hésite pas à me dire ce que tu en penses.
oh ! Mais, il ne faut pas ressortir les vieux billets comme cela, ça fait souvent mal ;-)
Mais dans ce cas, désolé de te contredire, mais ce n'est pas exactement cela. La dernière version des schémas RDF du Dublin Core (datant du 14/01/2008) ne précise pas de co-domaine (rdfs:range correspondant aux types de données ou de classe en objet d'un triplet) aux propriétés dc:subject et dcterms:subject. Par conséquent, s'il n'y a pas de restrictions, tu peux tout aussi bien utiliser un littéral qu'une ressource (donc une URI) avec n'importe quelle classe. A l'inverse, par exemple, la propriété dcterms:identifier demande explicitement un littéral en co-domaine (à noter que cette précision n'existe pas pour dc:identifier) et la propriété dcterms:coverage demande une ressource de type dcterms:LocationPeriodOrJurisdiction en co-domaine ( à noter que cette précision là aussi n'existe pas pour dc:coverage).
Mais, je suis d'accord avec toi, il est assez complexe de s'y retrouver. Et maintenant je vais aller mettre mon grain de sel chez toi :-)