Les petites cases

SKOS, l'avenir de la folksonomie ?

Commentaires

Tiens, tu devrais jeter un coup d'oeil la dessus à moins que ça ne soit deja fait ;) http://lists.w3.org/Archives/Public/semantic-web/2005Mar/0167.html et http://www.holygoat.co.uk/projects/tags/ Dans le meme genre d'idée, je bosse en ce moment sur une autre approche pour lier ontologies et folksonomies (démo prévue à blogtalk). En tout cas, j'aime bien l'idée que chacun puisse avoir sa propre définition de relations (un peu comme la réification que propose l'article plus haut, mais avec le côté décentralisé en plus)
Merci Alex. Je connaissais ce vocabulaire RDF dont, j'avoue, je ne vois pas bien l'intérêt puisque Dublin core et SKOS offre déjà tout ce qu'il faut pour répondre à ces besoins, me semble-t-il ?
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.
Pour le vocabulaire précédent, il me semblait que l'idée était assez proche de la tienne: utiliser SKOS pour définir des tags proches (meme s'il se contente juste de skos:related), gerer les similarités et contextualiser le tout. Concernant le lien entre folksonomie et ontologie, l'idée et de "lier les tags" non pas entre eux, mais en associant un ou plusieurs tags aux concepts/instances d'une ontologie. Par ex, notre modèle décrit que le 14è est un arrondissement de Paris. Les tags "Paris" et "75014" sont associés à ces instances. Ensuite lors de la recherche de photos, on demande de considérer Paris et ses arondissements. Ou bien juste ses rues. Ou encore les arrondissement de toutes les capitales, etc ... à partir du moment ou il y a suffisament de connaissances dans l'ontologie, et les liens vers les tags de la folksonomie. C'est plus "contraignant" dans le sens ou il faut définir l'ontologie et ses instances, mais plus expressif. Tout dépend du besoin en fait
Merci pour la précision. Je comprends mieux la nuance. J'ai abordé le principe que tu exprimes dans mon précédent billet, lorsque je parlais d'un vocabulaire défini par les administrateurs de Flick'r. En fait, cela revient à mettre en place un vocabulaire référentiel (cela pourrait être une ontologie, mais cela me semble compliqué, un thésaurus bien conçu doit suffire dans ce cas-là) que l'on peut lier avec son propre référentiel (que ce soit une folksonomie ou un thésaurus). Ton idée est précisément la vocation même de SKOS : définir un vocabulaire (d'un glossaire à un thésaurus, SKOS couvre un large spectre de l'ontology spectrum d'où son intérêt), le mettre à disposition et donner les moyens de lier ces propres données RDF avec ce vocabulaire.

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 :-)

Poster un nouveau commentaire

Le contenu de ce champ ne sera pas montré publiquement.
  • Les adresses de pages web et de messagerie électronique sont transformées en liens automatiquement.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • You may post code using <code>...</code> (generic) or <?php ... ?> (highlighted PHP) tags.

Plus d'informations sur les options de formatage

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
1 + 5 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.