ZEP-32 : Connexion des contenus - les relations

a marqué ce sujet comme résolu.
Cartouche
ZEP 32
Titre Connexion des contenus - les relations
Révision 3
Date de création 13/05/2015
Dernière révision 29/09/2015
Type Feature
Statut Rédaction

Aujourd'hui, le contenu sur Zeste de Savoir se résume à une liste de tutoriels et d'articles ne partageant rien de plus que des auteurs et des tags. Très peu d'informations donc rendent compte de la manière dont ils interagissent.

Cette ZEP cherche à pallier ce manque afin d'aider les lecteurs à naviguer parmi les contenus. À cet effet, nous souhaitons établir des liens entre les contenus, pour rendre compte de leurs relations.

Dans la suite, le terme « tuile » désignera un contenu (tutoriel, article, chapitre, message sur le forum, etc. : ça reste à spécifier) qu'on peut connecter aux autres.

Pour ceux qui se demanderaient comment se positionne cette ZEP par rapport à celle sur les parcours, l'objectif ici est de créer une carte IGN, tandis que les parcours font office de voyages organisés.

Notion de relation

Que signifie « être en relation » pour deux tuiles ?

Tout simplement, qu'il existe une raison, peu importe laquelle, qui permet de les rapprocher, de les relier. Cette raison peut être un auteur en commun, une date de publication identique, des tags partagés, un même sujet (les fonctions en Python), un même thème (Python), une longueur de titre identique, le fait que l'un est nécessaire à l'autre, aide à comprendre l'autre… Bref, c'est très vague et c'est pourquoi il faut spécifier cela.

Pour deux tuiles données, il existe alors deux possibilités de rendre compte des relations les connectant :

  • Une liste de tout ce qui nous passe par la tête et qui les mette en relation (cf. énumération précédente) ;
  • Une liste de relations satisfaites parmi un nombre fini de relations déterminées.

La première solution permettrait de rendre compte en détails des relations entre deux extraits mais poserait deux problèmes : certaines informations seraient superflues et ce système serait pas assez stricte pour être exploitable automatiquement par la suite. Effectivement, cette méthode reviendrait à commenter ses fonctions comme suit.

1
2
3
4
5
6
7
8
def f(arg1, arg2):
    """L'argument arg1 est un entier naturel représentant le nombre d'orteils
    pourris de la grand-mère considérée. Le second argument, arg2, désigne 
    quant à lui le nom de ladite grand-mère, sous forme d'une chaîne de 
    caractères.
    """

    print("La grand-mère {} a {} orteils pourris.".format(arg2, arg1))

Demandez à Sphinx1 de gérer des docstrings2 de ce type et il va vous cracher à la figure.

Il semble donc préférable de définir un nombre fini de relations possibles, ce qui permettrait par exemple d'effectuer du tri (liste des tuiles nécessaires à untel, du même auteur, etc.), de générer des parcours (cf. ZEP-31) personnalisés… Cette seconde méthode s'apparente à :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
def f(arg1, arg2):
    """
    :param arg1: Nombre d'orteils pourris de la grand-mère
    :param arg2: Nom de la grand-mère

    :type arg1: int
    :type arg2: str
    """

    print("La grand-mère {} a {} orteils pourris.".format(arg2, arg1))

Là, Sphinx est beaucoup plus courtois (et efficace !).

Il semble donc judicieux de se restreindre à un nombre fini de relations rigoureusement déterminées. Dans la suite, nous utiliserons le formalisme des relations binaires, qui fournit une manière rigoureuse de décrire les relations ainsi que de bénéficier d'un certain nombre d'outils mathématiques (notion de maximum pour les relations d'ordre, de classe d'équivalence pour celles d'équivalence, etc.).

Les relations à proprement parler

Prenons $A$ et $B$ deux tuiles quelconques et inspirons-nous de ce message de SpaceFox pour définir les rapports entre les tuiles à mettre en valeur, et via quelles relations.

Quelles tuiles lire avant celle courante ?

  • Nécessité

$A$ est en relation avec $B$ si la compréhension de $A$ est nécessaire à celle de $B$. Cette relation binaire est transitive.

Elle permettrait de dresser la liste des tuiles constituant des pré-requis pour une autre.

  • Utilité (accessoires)

$A$ est en relation avec $B$ si la compréhension de $A$ est utile à celle de $B$, sans pour autant lui être nécessaire. Cette relation est transitive.

Elle permettrait de lister les tuiles aidant à la compréhension mais demeurant facultatives.

  • Similarité

$A$ est en relation avec $B$ si $A$ et $B$ véhiculent les mêmes connaissances. Cette relation est réflexive, transitive et symétrique. C'est donc une relation d'équivalence. Par exemple, s'il existe deux tuiles sur les variables en Python (parce que l'auteur de la plus récente n'était pas satisfait de la plus ancienne), celles-ci seraient marquées comme similaires.

Elle interviendrait quand deux personnes souhaitent expliquer une même chose de deux manières différentes et permettrait d'éviter de « doubler » les pré-requis. Pour reprendre l'exemple, je n'aurais à consulter qu'une seule des deux tuiles à propos des variables pour satisfaire le pré-requis de la tuile sur les fonctions.

Quelles tuiles lire après celle courante ?

  • Paternité (cross-selling)

$A$ est en relation avec $B$ si $A$ et $B$ possèdent un auteur en commun. Cette relation est réflexive, transitive et symétrique. C'est donc une relation d'équivalence.

Elle remplirait le rôle de la section « Du même auteur » qu'on rencontre dans les bouquins. En effet, même si c'est plus rare pour du contenu technique, il est possible qu'un lecteur soit intéressé par des textes partageant le même style d'écriture, la même pédagogie que celui consulté. Ces conditions sont généralement réunies quand il y a un auteur commun.

  • Thématique (cross-selling)

$A$ est en relation avec $B$ si $A$ et $B$ partagent un même tag. Cette relation est réflexive, transitive et symétrique. C'est donc une relation d'équivalence. Par exemple, à la fin d'un tutoriel sur les décorateurs en Python, on est probablement intéressé par d'autres fonctionnalités du langage.

  • Approfondissement

$A$ est en relation avec $B$ si $A$ approfondit les connaissances diffusées par $B$. C'est une relation transitive et antisymétrique. Par exemple, un extrait sur les décorateurs en Python est un approfondissement d'un extrait sur les fonctions en Python.

Si $A$ approfondit $B$, $B$ est obligatoirement nécessaire à $A$. Toutefois, la réciproque est fausse. En effet, il est nécessaire en Python de connaître la notion de variable pour assimiler celle de fonction, mais cette seconde n'approfondit pas la première au sens strict. En revanche, une tuile allant plus loin dans l'explication de notion de fonction (par exemple, une fonction est un objet quelconque, on peut donc en passer en paramètre d'autres fonctions ; dans un cours destiné aux débutants, une telle information ne serait pas mentionnée) approfondirait la précédente.

De plus, si $A$ approfondit $B$, $A$ partage nécessairement un tag avec $B$. Mais là aussi, la réciproque est fausse. En effet, « Les espaces vectoriels » et « Les développements limités » partageraient le tag « Mathématiques », mais aucun n'approfondit l'autre.

  • Remplacement (remplacement)

$A$ est en relation avec $B$ si $B$ est obsolète et que $A$ se substitue à lui. C'est relation est transitive. Par exemple, un tutoriel sur PDO serait en relation avec un tutoriel sur mysqli.

Elle permettrait, une fois une tuile désuète lue, de se mettre à jour en consultant son homologue moderne. On peut aussi ranger cette relation dans la catégorie précédente, puisqu'elle permettrait carrément de ne pas lire la tuile périmée.

Administration

Seule l'équipe de validation a le droit de créer, modifier et supprimer des relations. Elle devra bénéficier d'une interface pour cela.

Quand une relation est supprimée, tous les liens correspondants le sont également, et les auteurs des tuiles affectées reçoivent une notification.

Il faut également un moyen de prévenir les personnes créant les liens de l'ajout d'une relation, qu'elles puissent utiliser cette dernière pour connecter les tuiles.

Mise en relation

Se référer à la ZEP-35.

Merci.

PS : les commentaires relatifs à cette révision commencent ici.


  1. Sphinx est un générateur automatique de documentation pour Python : à partir des commentaires que vous faites dans le code, il génère de beaux fichiers PDF, Markdown et compagnie. 

  2. Une docstring est un commentaire permettant de décrire une fonction : type et signification des arguments, de la valeur de retour, rôle de la fonction, exceptions levées, etc. 

+5 -0

Tu te douteras que je trouve cette proposition bien plus efficace que la ZEP-31.

Il me reste néanmoins une question cruciale : qui crée les liens? Sont-ce les auteurs? Sont-ce les modérateurs? Sont-ce les lecteurs(par exemple un vote collaboratif)?

J'aime beaucoup ta définition mathématique des relations. Elle est claire et permet de définir avec une certaine souplesse les choses.

Notamment, elle permet de savoir le sens de parcours de la carte. Ce qui permet vraiment d'utiliser la théorie des graphes.

Maintenant, tu es dans une ZEP, alors il va falloir que tu développes un petit peu son périmètre :

  • est-ce que tu veux juste un backend exploitable depuis une API?
  • est-ce que tu veux mettre en place une expérience utilisateur particulière (dès lors c'est casiment la première chose à spécifier)?
  • est-ce que seules les ressources internes sont acceptées? Est-ce que je peux dire qu'une fiche wikipédia, un tuto OC, une vidéo d'e-penser est un prérequis (relation de nécessité) à mon tuto?
  • est-ce seuls les contenus de type tuto/article sont autorisés? Les forums? les tribunes libres (serpent de mer de zds)?

Tu te douteras que je trouve cette proposition bien plus efficace que la ZEP-31.

Je pense qu'elles sont complémentaires (cf : mon dernier message sur le sujet de la ZEP-31). Je me suis seulement planté sur la spec' de la ZEP-31.

Il me reste néanmoins une question cruciale : qui crée les liens? Sont-ce les auteurs? Sont-ce les modérateurs? Sont-ce les lecteurs(par exemple un vote collaboratif)?

Le dernier paragraphe de la partie Le contenu semble répondre à ces questions. ^^

  • est-ce que tu veux juste un backend exploitable depuis une API?

Je doute avoir les compétences nécessaires pour répondre à cette question. Mais avoir une API permettrait d'obtenir un truc utilisable partout, non ?

  • est-ce que tu veux mettre en place une expérience utilisateur particulière (dès lors c'est casiment la première chose à spécifier)?

Ouep, c'est la partie Interface. Pensant utiliser un graphe, Eskimon m'a devancé ici.

  • est-ce que seules les ressources internes sont acceptées? Est-ce que je peux dire qu'une fiche wikipédia, un tuto OC, une vidéo d'e-penser est un prérequis (relation de nécessité) à mon tuto?

Non, uniquement les ressources internes. On n'a aucun contrôle sur les autres. L'objectif est d'aider les lecteurs à se repérer sur ZdS, pas sur le Web dans son intégralité.

  • est-ce seuls les contenus de type tuto/article sont autorisés? Les forums? les tribunes libres (serpent de mer de zds)?

Uniquement les tutoriels et les articles. Le reste est plus du ressort de la ZEP-15 me semble-t-il.

Merci. =)

+1 -0

Le dernier paragraphe de la partie Le contenu semble répondre à ces questions. ^^

Le problème c'est que tu "suggères". Cela signifie que pour toi c'est un détail. MAIS : si c'est l'auteur qui décide, c'est lui qui prend l'initiative d'ouvrir ou fermer des chemins, notamment entre les tutos et les articles (et vice versa). Si ce sont les validateurs, alors c'est le rôle d'éditeur de zds qui est mis en avant. Si ce sont les utilisateurs alors cela s'inclue dans leur expérience long terme.

Tu ne seras peut être pas d'accord avec moi, mais à mon humble avis, cette question est centrale.

Ouep, c'est la partie Interface. Pensant utiliser un graphe, Eskimon m'a devancé ici.

Alors on se retrouvera avec le même problème qu'a eu OC avec sa carte de l'univers. Le jeu de la carte est utile si tu es dans l'optique "je veux suivre un parcours, et je veux savoir où j'en suis".

A mon sens, de telles relations peuvent être représentées de manière bien plus simples et agréables pour les gens : un encart avant l'intro pour les prérequis, un encart après la conclusion pour les ouvertures.

Non, uniquement les ressources internes. On n'a aucun contrôle sur les autres. L'objectif est d'aider les lecteurs à se repérer sur ZdS, pas sur le Web dans son intégralité.

Ok. Je trouve ça dommage mais au moins c'est clair.

Uniquement les tutoriels et les articles. Le reste est plus du ressort de la ZEP-15 me semble-t-il.

La navigation par facette? Je sais pas.

Je doute avoir les compétences nécessaires pour répondre à cette question. Mais avoir une API permettrait d'obtenir un truc utilisable partout, non ?

Oui, mais l'API ne signifie pas qu'on aura une interface graphique, elle ne dit rien à ce propos. A l'opposé, partir de l'UX pour en déduire que l'API est une solution envisageable est une conception totalement différente. Aujourd'hui ZDS est conçu dans le sens "on développe le backend technique et après on voit", ça crée une page de tuto qui au bout d'un an a juste été légèrement restylée mais qui est toujours aussi illisible. Et tant d'autres choses. La question peut se poser.

Petite question "technique" : comment garantir que les relations symétriques le soient vraiment si on laisse le choix aux auteurs ? Après tout, on pourrait avoir un auteur qui décide que son tutoriel A a un lien avec B, mais l'auteur du tutoriel B n'est pas d'accord. Mon avis est qu'il vaut mieux laisser cela aux validateurs.

Ouep, c'est la partie Interface. Pensant utiliser un graphe, Eskimon m'a devancé ici.

Alors on se retrouvera avec le même problème qu'a eu OC avec sa carte de l'univers. Le jeu de la carte est utile si tu es dans l'optique "je veux suivre un parcours, et je veux savoir où j'en suis".

A noter que mon graphe ne propose aucun lien hein, c'est juste une facon differente de representer le menu des tutoriels finalements (decoupage theme/categorie/tutos)

+0 -0

A mon sens, de telles relations peuvent être représentées de manière bien plus simples et agréables pour les gens : un encart avant l'intro pour les prérequis, un encart après la conclusion pour les ouvertures.

Dans un premier temps, on pourra effectivement se cantonner à ça. Mais il faudra un jour qu'on ait une belle page "Tutoriels".

Ok. Je trouve ça dommage mais au moins c'est clair.

Hum… ce n'est pas à moi de décider me semble-t-il mais à tout le monde. Donc si tu as des arguments en faveur des ressources externes, n'hésite pas. ^^

+0 -0

En fait je suis perdu : quel est l'objectif de cette ZEP ? En particulier, a-t-elle pour but de créer des parcours de connaissances (« Le calcul scientifique en Python », « Prise en main rapide du protocole WAMP », « Apprendre l'allemand »…) ?

+0 -0

En fait je suis perdu : quel est l'objectif de cette ZEP ? En particulier, a-t-elle pour but de créer des parcours de connaissances (« Le calcul scientifique en Python », « Prise en main rapide du protocole WAMP », « Apprendre l'allemand »…) ?

Vayel

Pour moi ca c'est des titres de tuto… Un parcours serait plutot "apprendre le python" ou "Faire un site web" ou encore "les mathematiques et l'informatique" ou bien "le traitement d'images"

+3 -0

En fait je suis perdu : quel est l'objectif de cette ZEP ? En particulier, a-t-elle pour but de créer des parcours de connaissances (« Le calcul scientifique en Python », « Prise en main rapide du protocole WAMP », « Apprendre l'allemand »…) ?

Vayel

J'avoue personnellement que je suis assez étonné que tu demandes à quoi sert ta propre ZEP. Ou alors, y'a quelque chose de vraiment pas clair dans ta question.

@SpaceFox :

Je pense qu'il parle de la ZEP 15 et de son scope :

Depuis : améliorer simplement le menu (catégorisation / regroupement / rangement) jusqu'à créer un parcours complet pour quelqu'un qui veut créer un site web (et donc doit passer par la case page statique, page décorée, rendu côté serveur, rendu côté client, …) donc qui établirait un "lien" (c'est tout le noeud de la question) entre :

  • Apprendre l'HTML 5
  • Une feuille de style, c'est quoi ?
  • Débutez avec Python
  • Faire un site web avec Django
  • Mettre en place une API avec DRF
  • Des pages dynamiques en Angular

Avec, par exemple, le dernier qui est relié à l'avant-dernier, mais également avec un cours sur Spring MVC, un autre sur le JS "vanilla", …

Y'a clairement des points de recoupement entre les deux ZEP je pense. Mais je dirais que celle-ci englobe la ZEP 15. Faut démêler le problème pour faire le rapprochement entre une facette d'un cours et des liens entre deux cours. Je pense (mais franchement c'est flou dans mon esprit…) qu'une facette se rapproche de ce que Vayel appelle une relation de similarité (deux sujets traitent de la mise en place d'une API REST dans deux langages différents par exemple) mais que du coup sa ZEP va plus loin, en introduisant d'autres concepts relationnels.

J'irais jusqu'à dire (sans grande conviction…) qu'une facette est l'implémentation technique d'une relation de similarité.

+0 -0

@Javier, OK, mais du coup non, une facette ce n'est absolument pas ça.

La navigation à facettes (l'objet de la ZEP-15), c'est uniquement la manière de naviguer dans les tutos. On n'y parle pas vraiment de définir des liens pour leur donner du sens, mais plutôt de la manière d'exploiter ces liens pour que le lecteur trouve rapidement, facilement et efficacement ce qu'il cherche.

Ce qui me fait dire que contrairement à ce que laissent penser les commentaires de la ZEP-15, la notion de navigation à facettes n'est absolument pas comprise. Il va falloir que je trouve de meilleures explications.

@Eskimon : Le problème c'est qu'on ne peut pas considérer que ce sont des tutoriels. En effet :

  • « Le calcul scientifique en Python »

Je doute que quelqu'un publie un jour un tel tutoriel. Par contre, on peut raisonnablement en avoir sur numpy, scipy, matplotlib, pandas…

  • « Apprendre l'allemand »

Pareil. On a un tutoriel « La déclinaison de l'adjectif en allemand », bientôt un autre « La conjugaison de l'allemand ». Peut-être qu'un jour, tout le contenu technique pour apprendre l'allemand sera présent sur ZdS mais pas sous forme d'un tutoriel.

  • « Prise en main rapide du protocole WAMP »

Je travaille (lentement) sur un tutoriel intitulé « Le protocole WAMP », comportant une approche historique, une description de l'architecture (routeur + composants), une jutification du principe des messages, une introduction à RPC et PubSub, un TP et une annexe. Mais dans la pratique, on n'a besoin que de connaître l'architecture, RPC et PubSub pour utiliser le protocole. Le reste n'est pas nécessaire. Du coup, comment passer de « Le protocole WAMP » à « Prise en main rapide du protocole WAMP », sachant que le second ne fait que filtrer du contenu du premier ?

Mais il s'agirait plutôt de la ZEP-31 en effet.

@SpaceFox :

C'est bien ce que je me demande et je peux t'assurer que ça m'étonne aussi. Le problème c'est qu'on a un besoin, guider les lecteurs, et deux problématiques, à mon sens bien réelles : gérer les cas mentionnés au paragraphe précédent (ZEP-31) et établir des relations entre les contenus pour les repérer les uns par rapport aux autres (ZEP-32) ; du coup je me demande si la ZEP-32 ne permettrait pas de résoudre la problématique de la ZEP-31.

Pas besoin de reprendre le contenu, on peut simplement les lier entre eux.

Kje

De plus, « établir des relations » c'est très vague : je m'interroge sur l'objectif de telles relations.

+0 -0

On peut constater que les relation "Thématique" n'est pas très précise. En effet, partager un tag, ce n'est pas pareil qu'en partager trois. Or il semble indispensable de rendre compte de cette différence.

Une première solution consisterait à créer autant de liens "thématique" entre deux extraits qu'il y a de tags en commun. Ca me paraît un peu lourd.

Une seconde solution consisterait à introduire la notion de force d'une relation. Cette information rendrait compte de l'intensité de la relation connectant deux extraits. Pour "thématique", elle se mesure à partir du nombre de tags en commun, pour "paternité", à partir du nombre d'auteurs en commun, pour "utilité", elle permet de savoir à quel point l'extrait est utile, pour "approfondissement", elle rend compte du nombre de points approfondis…

Qu'en pensez-vous ?

+0 -0

La seconde solution me paraît pertinente.

Si on laisse le choix des relations au staff, on peut imaginer que l'auteur fasse des suggestions du type "Je pense que mon tutoriel approfondit trois points du tutoriel XYZ".

Le seul cas problématique, c'est l'utilité : elle est relative à chacun et donc difficile à caractériser.

Si on laisse le choix des relations au staff, on peut imaginer que l'auteur fasse des suggestions du type "Je pense que mon tutoriel approfondit trois points du tutoriel XYZ".

Ouep, on peut prévoir un champ à cet effet. Mais de toute manière, tout le monde pourra envoyer un MP pour faire des suggestions (voire dans les commentaires du tutoriel).

Le seul cas problématique, c'est l'utilité : elle est relative à chacun et donc difficile à caractériser.

Comment ça ? Relative pour ceux qui la créent (cet extrait est-il utile à tel autre ?) ou pour le lecteur (en fonction de son baggage de connaissances) ?

Dans le premier cas, cela vaut pour toutes les relations. Dans le second, on considérerait que le lecteur ne possède aucune connaissance sur le sujet. Le cas échéant, il sera content d'être conseillé sur ses lectures. Dans le cas contraire, il n'aura qu'à ne pas lire l'extrait concerné.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte