Sémantique MédiaWiki : Différence entre versions

Version du 7 février 2017 à 14:01

Accéder à la page Semantic MediaWiki de OSE

Quelques liens et conseils préalables :

Tutoriel en vidéo sur l'utilisation de formulaires

Informations de bases par MediaWiki

Informations de bases par Semantic MediaWiki

Il est possible à tout moment (et sur tous les Wikis) d'avoir accès aux codes en cliquant sur "Modifier" ; il ne faut pas hésiter à s'inspirer, comprendre le fonctionnement ou l'affichage visible sur les autres Wikis.

Définitions

Propriété

Définir une propriété

Les propriétés peuvent être vues comme les "variables" du wiki ; une propriété va prendre un genre de valeur défini par l'utilisateur. Par exemple, si je créer la catégorie "Prénom", je vais pouvoir stocker des valeurs comme "Pierre", "Lucas", "Clémence" (notamment au travers de formulaires, voir plus loin). Ainsi, lorsque je souhaiterais par la suite afficher la liste des prénoms, ou plus précisément la liste des Prénom "Pierre" enregistrés, j'utiliserais la propriété Prénom (au travers d'un test d'égalité proche de ce que l'on retrouve dans de nombreux langages informatiques).

Type

De plus, il est possible d'imposer un type à une nouvelle propriété créée : dans le cas général, pour éviter de contraindre l'utilisateur lorsqu'il rentre une valeur dans une propriété, il est commode d'utiliser les types "text" ou "page" (en fonction de besoin). Mais il est possible de choisir des types comme Number ou E-mail ; ainsi, lors de la saisie, l'utilisateur se verra refuser la valeur s'il ne correspond pas au format attendu.

Par exemple, si la propriété Age est du type Text, elle acceptera les valeurs "25", "douze ans" ou encore "voiture" et sera difficilement exploitable par la suite (si l'on souhaite par exemple voir les personnes âgées de plus de 20 ans. Si elle est du type Number, le tri sera alors possible.

Restreindre les valeurs

Enfin, il est possible de restreindre les choix à une série de valeurs au moment de définir la propriété ; à noter qu'il est toujours possible d'ajouter ou de supprimer des valeurs en modifiant la propriété par la suite. Par exemple, on peut définir la propriété "Lancer de pièce" et imposer les valeurs "Pile" et "Face" seule. Encore une fois, restreindre des valeurs sera utile lors des possible tris à effectuer par la suite (n'afficher que les personnes qui ont fait "Pile", i.e. où la propriété Lancer de pièce=Pile).

Remarque importante : Attention à la syntaxe des valeurs "permises" par la suite : autoriser "PILE" et "face" rédiger ainsi a pour conséquence de ne renvoyer aucun résultat lors des requêtes comportant les tests d'égalités Lancer de pièces = "Pile", "pile", "Face" ou encore "FACE". Il est donc judicieux d'adopter la même syntaxe au sein d'une (ou de toute) propriété. J'ai pour ma part adopté la convention "première lettre en majuscule, reste en minuscule".

Modèle

Le modèle (ou Template) peut-être vu comme un patron. Typiquement, toute partie de texte ou de mise en page apparaissant de nombreuses fois peut être mis sous la forme d'un modèle. Les zones variables d'un modèle peuvent ainsi être mise en "paramètres".

Par exemple :

Après la création du Template "Profil utilisateur", ces deux codes affichent le même résultat. Ici, il y a 2 paramètres : "Antoine" et "21". On verra plus tard qu'il est encore possible d'optimiser cette écriture si "Antoine" possède déjà un profil enregistré avec son âge. Les paramètres lors de la définition du Template apparaissent entre triple accolades. Ainsi, dans notre exemple, le Template "Profil utilisateur" serait défini ainsi :

Profil utilisateur : {{{1}}}
Ceci est le profil de {{{1}}} sur le site d'OSE. Il est actuellement âgé de {{{2}}} ans.  
Il est possible de créer son propre profil, ou de modifier son profil ici.

On remarque alors que sur une page affichant plusieurs fois différent "profil utilisateur", le gain de temps et de place est important.

A noter qu'il est possible de combiner ces modèles avec des requêtes, d'autres modèles, etc...

Formulaire

Les formulaires font le pont entre l'utilisateur et la base de données. Il s'appuie sur un modèle et des propriétés (à définir au préalable). L'utilisateur stocke alors des valeurs dans des propriétés, le tout organisé dans un modèle. Pour le formulaire "Profil", la partie à identifier est la suivante (le reste étant des explications, ou de la mise en page) :

{{{for template|Profil}}}
{| class="formtable"
! Nom prénom, ou pseudo: 
| {{{field|Nom prénom, ou pseudo|mandatory}}}
|-
! Avatar: 
| {{{field|Avatar}}}
|-

...

! Linkedin:
|{{{field|Linkedin}}}
|}
{{{end template}}}

On voit ainsi clairement le modèle qui a été utilisé (le Template "Profil"). La mise en page est du type tableau, ce qui explique la mise en page du type " {| ....|.... |-....|....|} ". Enfin, le nom des champs (ce que verra l'utilisateur du formulaire) est précédé d'un point d'exclamation, et les champs dans lesquels les utilisateurs vont rentrer leur valeurs sont donnés entre triple accolades également. Par exemple, {{{field|Nom prénom, ou pseudo|mandatory}}} est un champ (type field), la propriété dans laquelle va être stockée la valeur est "Nom prénom, ou pseudo" et il est mentionné en plus "mandatory" (rendant ce champ obligatoire). Pour plus de détails sur liste des paramètres d'un champ, se référer aux liens mis en début de page.

Requêtes

Les requêtes peuvent être de plusieurs types. J'ai pour ma part utilisé deux types de requêtes : la requête #ask et la requête #show. A l'aide des définitions données ci dessus et des exemples implémentés durant ce stage, je vais tenter d'expliquer leur fonctionnement. Il suffira de cliquer sur "Modifier" des liens ci dessous pour voir la requête.

Affichage des membres des différents cercles :

• Code accessible ici : Cercle_budget_&_financement#Membres

#ask:[[Cercle::Budget & financement]] est une requête qui ne va retenir que la valeur Budget & financement de la propriété Cercle. Dans le cas d'un test d'égalité entre une propriété (Cercle) et une de ses valeurs (Budget & financement), la syntaxe est "2 fois deux points" comme visible ci dessus.

La propriété Cercle apparaît dans le formulaire "Profil", donc cette propriété est reliée aux autres propriétés du formulaire "Profil". Ainsi, il est possible de faire apparaître les valeurs de ces autres propriétés, comme le pseudo : |?Pseudo=Nom ou pseudo. La barre verticale est due à la mise en page des résultats (tableau). Ici, on questionne la propriété "Pseudo" des résultats retenus après la requête #ask. La partie =Nom ou pseudo permet de renommer la colonne du tableau. La même mécanique est reproduite pour le "Groupe Local" et les "Autres Cercles".

Enfin, en dessous, de la mise en page : par exemple, |headers=show permet l'affichage des titres des colonnes et |sort=Pseudo sort les résultats par ordre alphabétique des pseudos.

Glossaire

Formulaire & Propriétés

• Form:Definir utilisant le Template Template:Definir

Ce formulaire permet de relié les propriétés (qui ont été créées en parallèle) suivantes : Définition, Description, Fournisseur, Lien, Compétences et Projet.

A noter que la propriété Compétences était déjà présente dans le formulaire "Profil" : elle est donc reliée aux nouvelles propriétés énoncées ci-dessus mais également à celles de Profil. On observe des paramètres de champs supplémentaires :

• input type= impose un nouveau type de champ (listbox pour un menu déroulant, textarea pour un champ large,...)
• placeholder= fait apparaître un message grisé disparaissant au clic de l'utilisateur.
• default= assigne une valeur par défaut au champ, pratique pour les filtres (de plus, je l'utilise car lorsque qu'un champ est laissé vide, il y un décalage entre valeur stockée et champ. On a alors la valeur du champ stockée dans la mauvaise propriété).

Ce formulaire permet ainsi de stocker les définitions des utilisateurs. En l'associant à la catégorie Définitions, il est possible de voir toute les définitions rentrées.

Référencer les définitions

Le Template Ref est relativement court : {{ #tag:ref| {{ #show: {{{1}}} | ?Description }} }}. L'appel à ce Template est simplement : {{Ref|Terme à définir}}.

Le #tag:ref| met juste en référence le contenu qui le suit.

La requête {{ #show: {{{1}}} | ?Description }} est une requête qui a l'avantage d'être inline, c'est à dire qu'aucune mise en page ne lui est associée : le résultat apparaît en brut dans le texte. Dans ce cas, on demande de "montrer" la valeur de la propriété Description du terme qui a été mis en paramètre. Si je veux la définition de "Voiture", en écrivant {{Ref|Voiture}}, je mets en référence la description du terme "Voiture".

A noter que la propriété associée à la valeur "Voiture" (qui est Définition) n’apparaît pas, contrairement à une requête #ask (on on aurait eu #ask:[[Définition::Voiture]])

Afficher les résultats

Ensemble du Glossaire :

• Code disponible ici : Glossaire

Il s'agit d'une requête #ask comme visible précédemment, la seule différence étant qu'il n'y a pas de "Définitions" particulières à afficher ; pour toute les afficher, on utilise donc #ask:[[Category:Définitions]] qui va afficher toute les définitions de la catégorie "Définitions". Puis on affiche la propriété Definition et Description de ces entités.

Par Projet ou par Domaine de compétences :

Plutôt que de "copier-coller" une même requête, on va utiliser un modèle. La démarche étant analogue entre un tri par projet ou par domaine de compétence, l'explication sera faite pour le tri par Projet.

• Le Template "AffichageDef" est disponible ici : Template:AffichageDef

Le Template associé est appelé de la manière suivante : {{AffichageDef|Nom du projet|Page_Du_Projet}}. Dans un premier temps, on distingue le cas où une page est associé à un projet :

{{#if: {{{2}}} | La page associée à {{{1}}} est disponible [[{{{2}}}|ici]]. | }}

La formulation {{#if: contenu | Réponse 1 | Réponse 2}} est plutôt pratique : si le "contenu" existe/est non vide, il renvoie la réponse 1 ; sinon, il renvoie la réponse 2. Ainsi, dans notre cas, soit l'utilisateur rentre la page (paramètre 2) et dans ce cas une phrase avec le lien généré est renvoyer, soit il ne rentre rien et rien n’apparaît.

Ensuite, on retrouve un système de tri classique : #ask:[[Projet::{{{1}}}]]. Le paramètre 1 est le nom du projet, donc une valeur de la propriété Projet. (Pour le tri par domaine de compétence, on utilise juste la propriété "Compétence" mis sur une page dédiée, par exemple "Classification_des_définitions_d'Agriculture/Maraîchage/Permaculture").

Catégoriser les demandes par discipline :

• Voir la catégorie @Mécanique

Sur la page associée à la catégorie Mécanique, la requête de tri est un peu particulière. Comme dit précédemment, la propriété "Compétences" est présente dans le formulaire "Profil" et le formulaire "Definir". Ainsi,un simple filtrage des données de tous les formulaire ayant la valeur "Mécanique" pour la propriété "Compétences" ne suffisait pas. D'où :

#ask:[[Compétences::Mécanique]][[Pseudo::!NULL]]

Dans ce cas, on impose aux résultats d'avoir la propriété Compétences valant Mécanique ET la valeur de la propriété Pseudo non vide. Le formulaire de définition n'utilisant pas la propriété "Pseudo", la valeur de "Pseudo" est nécessairement nulle. Remarque : d'autres propriétés sont exclusivement dans le formulaire "Profil" et aurait pu être utilisées ; néanmoins, comme le but est d'afficher les noms des membres ayant des compétences en Mécanique, il est plus cohérent (et moins risqué pour la suite) d'imposer une condition sur le champ "Pseudo".

Pour le dire autrement, remplacer "Groupe local" par "Pseudo" aurait fonctionné, mais rien n'assure qu'un formulaire futur fasse apparaître la propriété "Groupe local" indépendamment des individus ; une partie des résultats serait alors inutile.

Remarque : le Template utilisé est le Template @, utilisé précédemment pour les "personnes".