Ce journal est la suite de Celui là.
Résumé de l'épisode précédent :
Magnus Manske est un Wikipédien de la première heure, un vrai, avec des poils et des gros seins1, un de ceux qui ont créés le moteur de wikis. Et Magnus est toujours dans le coin, il traîne du côté de Wikidata, et il a crée un outil pour scripter et chaîner les traitements sur des jeux de données issues de différents outil et les réutiliser avec les mêmes outils.
Seulement voilà, ça a encore l'air trop compliqué et il était tout seul à utiliser ce principe. Et il est pas content parce qu'un type comme ça croit forcément à la force de la coopération et du collectif. Et tout seul, ben c'est moins bien. Alors Magnus s'est creusé la cervelle et s'est demandé ce qui bloquait (peut être pas tout seul, je suis pas dans le secret des Dieux ^^). Le résultat implique la notion de "Pile de page". Vous avez bien entendu remarqué que le chemin d'une pile à un pipe n'est pas bien long.
On peut créer une Pile de plein de manières : une bête liste textuelle d'identifiants Wikidata, à partir d'une requête sur les moteurs Wikidata (SPARQL ou WDQ), une collection de bookmarks d'élément ou de page crées grâce à Gather, une catégorie Wikipédia ou autre wiki Wikimédia (autolist, et d'autres sans doute.
Ensuite on peut éventuellement combiner les piles : intersection, union, différence, … pour créer de nouvelles piles. Les piles nouvelles sont identifiées par un numéro qu'on peut tout à fait partager avec d'autres pour qu'ils les réutilisent pour leur besoin.
Enfin on a des outils "consommateurs" qui peuvent réutiliser les piles pour appliquer un certain nombre de traitement - exemple : créer un jeu du "Wikidata Game" de nettoyage manuel d'un jeu de donnée pas propre, trouver des images, créer en batch des déclarations sur les éléments d'une pile avec autolist …
Le tout constitue PagePile - Présentation de l'outil sur son blog), une boîte à outil collaboratif de traitement, une sorte de "pipe" interactif pour poursuivre l'analogie, un point de rencontre pour chaîner les outils et les faire rentrer dans un monde uniforme. Une boîte à outil de nettoyage et de partage de données totalement utilisable et fonctionnel. C'est une prouesse notable, c'est pas si simple de parvenir à faire un outil qui permet à des gens capables de faire une requête SPARQL complexe pour un résultat sophistiqué, par exemple, et de faire réutiliser le résultat à des gens pas du tout intéressés par cet aspect des choses - rien que le titre "PagePile" est révélateur à ce sujet : on parle de "page" pour ne pas dérouter les Wikipédiens qui sont familiers avec le concept de page wiki, et beaucoup moins avec le concept "d'item" - élément - Wikidata.
-
on pourra pas m'accuser de sexisme malgré l'outrance caractérisée de ce résumé /o\ ↩
# wikilien Magnus Manske
Posté par ZeroHeure . Évalué à 5.
Je me suis permis de corriger le wikilien Magnus Manske (trop de crochets)
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# tag
Posté par BAud (site web personnel) . Évalué à 2.
à partir d'une page, il n'aurait pas pu avoir ses tags et de là une liste de pages en relation ?
mais je n'ai peut-être pas compris le concept, ni le besoin initial, ni le résultat obtenu ? :/
bref, ça manque d'une nimage ;-)
[^] # Re: tag
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: tag
Posté par Thomas Douillard . Évalué à 3.
Pour la pas n'image : l'idée c'est que Wikipédia a en réalité pleins de données structurées - les infoboxes, les catégories, qui sont importables dans Wikidata, par exemple, mais que ces données ne sont pas totalement propres ou ultra bien structurée.
Du coup sa chaîne d'outil est capable, par exemple, d'importer par exemple tous les articles catégorisées dans une catégorie pour les traîter avec d'autres outils.
Ou encore quand on a de bonnes raisons de penser qu'un ensemble d'articles ont des images, on les gardes sous la mains pour faire un jeu collaboratif avec des propositions d'images probables. Ou quand on a de bonnes chances de penser que les articles catégorisées dans une catégorie sont des cinéastes, on a la possibilité de rajouter les déclarations "c'est un être humain" ou "son métier est réalisateur" automatiquement ou semi automatiquement dans Wikidata. Ou quand on sait qu'il y a eu des erreurs massives lors d'un import, on a une chaîne d'outils pour les nettoyer.
[^] # Re: tag
Posté par BAud (site web personnel) . Évalué à 3.
oui, j'en suis bien conscient, pour la gestion de référentiel : l'amélioration sautant directement à la vue est la qualité de la donnée, comme tu l'indiques, et l'étape d'après (on va dire en cible pour éviter que certains retiennent leur respiration en l'attendant pour hier) c'est la gestion des données de référence aussi appelé MDM mais ce sigle présente l'inconvénient, comme beaucoup de sigles de 3 lettres de signifier plusieurs choses, aucun rapport (ni même avec Karamazov, j'suis fils unique).
je ne parlais pas d'images dans le contenu mais de générer des stats grâce à wikidata et les représenter graphiquement, à l'heure du big data, j'imagine qu'il y a bien quelqu'un qui a sorti projet R(*) pour produire des statistiques et des graphismes intéressants sur wikidata : ce serait plus vendeur, plus imagé et sémantiquement intéressant ;-) (pour ceux aimant les stats).
Pour ce qui est de la sémantique dont tu parles, c'est de la meta-data, ce qui se traduit par des tags, de la normalisation des formats selon le domaine, ça je pense que cela fonctionne bien… ça reste améliorable sémantiquement comme sur LinuxFr.org à comparer à toutes les demandes sur les tags mais bon… le jour où les tags seront compris, je sors le champagne (les 10 boîtes de six). Ajouter sémantique, c'est bon, je mets 1 € et quand ça arrive je rince tout le monde avec un invest' sur un rendement à 2% (mon livret A suffirait si son taux ne cessait de baisser), je laisse le calcul du nombre d'années à titre d'exercice :-)
Une image vaut 1000 mots :-)
(*) : oui, projet R est un nom déplorable pour les recherches sur Internet ou sur le web et même sur wikipedia… Vivement qu'ils changent de nom pour remplacer définitivement Excel en entreprise… (R is not S, aka RINS cela aurait déjà été mieux, et pourtant je l'ai fait en 10 sec, les acronymes ça a du bon parfois…)
[^] # Re: tag
Posté par Thomas Douillard . Évalué à 3.
J'ai rien compris. Wikidata c'est un projet de ce que tu appelles des "métadatas", mais pas forcément juste des métadonnées d'ailleurs mais tout simplement (Ex : la superficie de Nantes, par exemple indiquer le nombre d'habitant d'une ville ou de dire qu'une ville est une … ville.
Pour ce qui est du sémantique on va y arriver par ce genre de projet - créé par Markus Kroetch, un des créateur de Semantic MediaWiki et chercheur dans le domaine du web sémantique, créateur de https://www.mediawiki.org/wiki/Wikidata_Toolkit , une lib java pour jouer avec Wikidata et ses données) qui vont permettre de poser des règles de déduction de données à partir de données existantes façon ruleML probablement, modulo l'adaptation au modèle Wikidata qui est (juste) un peu plus haut niveau que du RDF normal (sans RDFS et les "contraintes molles" qui permettent de créer un modèle d'un peu plus haut niveau pour les différent domaine d'application genre "telle propriété ne devrait jamais s'utiliser avec cette autre" ou "il ne devrait y avoir qu'une seule valeur pour cette propriété dans un élément donné". Les contraintes ne sont qu'indicatives et n'empêchent jamais de rentrer des données, ça indique que ça n'a pas été fait proprement et qu'il y a peut être quelque chose à corriger. À l'heure actuelle, à part les conventions communautaire et textuelles, l'écriture de contrainte est ce qui se rapproche le plus d'un "modèle" de donnée comme un schéma de base de donnée "par dessus" du modèle de base Wikidata qui est un peu pauvre de ce point de vue de base, il n'y a même pas de notion de "classe" dans le modèle de base. Donc on doit décider comment ça se passe de manière collaborative, et c'est pas simple :)
Mais là ça n'a pas grand chose à voir, il s'agit simplement d'enrichir Wikidata. Principalement en rajoutant des "déclarations" Wikidata pour les éléments, en réutilisant les données présentes sur les Wikipédias. Par exemple à partir d'une catégorie mettons https://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Quartier_d%27une_ville_de_Su%C3%A8de par exemple, de rajouter aux éléments Wikidata des articles qui sont catégorisés à l'intérieur de rajouter des déclarations "nature de l'élément : quartier d'une ville de Suède" de manière semi automatique, en excluant les trucs que Wikidata sait ne pas être des quartiers, typiquement.
Ou de faire des "jeux" qui ressemblent à
par exemple avec la communauté qui répond aux questions posées, le tout à partir des jeux de données crées par X ou Y à partir d'une requête sur Wikidata, une liste d'élément confectionnée d'une manière quelconque, d'une catégorie Wikipédia, …
[^] # Re: tag
Posté par BAud (site web personnel) . Évalué à 2.
bah, le fait qu'il n'y ait que toi et moi en commentaire pour échanger, me fait penser que la présentation est trop abstraite pour convaincre quiconque n'est pas dans le sujet d'y participer :/
ce pourquoi, je proposais de trouver une image illustrant le concept ;-)
Exemples :
ou encore :
Bref, c'est bien de générer des meta-data, mais les mettre en image, cela le rend plus compréhensible àmha (plus concret, moins abstrait, bref).
[^] # Re: tag
Posté par Thomas Douillard . Évalué à 2.
Bon, je suis pas sûr que ce soit moins abstrait, mais un schéma de principe fait en deux secondes sur http://asciiflow.com/ :
Sinon parfois si il y a pas de commentaire ça veut dire qu'il y a rien à ajouter tellement le journal était bien :) Bon en général c'est mieux noté que ce journal ci /o\
[^] # Re: tag
Posté par BAud (site web personnel) . Évalué à 2.
tu bluffes martoni !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.