Nous cherchons à couvrir le besoin suivant :
- Comment ajouter des données au modèle de données de WikiNi sans étendre à l'infini le modèle de données.
- Ce problème ne se pose pas seulement pour les données de configuration, comme nous allons le voir.
Le principe : créer un méta-modèle de données simple dans lequel on va pouvoir créer d'autres modèles de données. Les triplets offrent cette possibilité.
Eventuellement, la solution pourrait permettre de partager des données entre plusieurs wikis.
Synthèse des discussions
- l'ajout d'une table de triplets ne modifie pas fondamentalement WikiNi en soi
- les triplets ne seront pas la solution à tous les problèmes, malgré leur haute généricité
- les triplets pourraient même compliquer la programmation de certaines requêtes
- les triplets peuvent en revanche nous débloquer facilement sur beaucoup de points en attente
- les triplets peuvent au minimum servir pour le stoquage des paramètres même de WikiNi
- la notion de triplets permet d'étendre les fonctionnalités sans plus changer de structure ensuite
Nous avons donc conclu qu'il était, dans tous les cas, intéressant d'implémenter cette notion, d'essayer ensuite de l'utiliser au maximum de ses possibilités, quitte à revenir ensuite sur ce choix en ré-implémentant certaines fonctionnalités avec autre chose que des triplets.
Tout cela reste bien sûr ouvert à discussion.
--
ProgFou (cité par
CharlesNepote d'après un mail)
Exemples de l'usage de triplets
- horodatages en tous genres : permet d'ajouter des fonctionnalités ; permet d'éviter par exemple certains types de vandalisme consistant en l'usage répeté d'une fonctionnalité
- métadonnées sur les utilisateurs
- variables de configuration des actions
- stockages de statistiques sur le wiki (nombre de pages à telle date, nombre de pages modifiées entre telle et telle date, etc.)
- des métadonnées sur le wiki en lui-même (date de création du wiki, créateur du wiki, etc.)
- des systèmes de vote
- des plannings
A mon sens les triplets sont plutôt utiles :
- pour des données qui ont un usage restreint par rapport à un ensemble d'entités d'un même type. Par exemple le fait que peu de pages soient simultanément en cours d'édition.
- pour des données qui sont uniques. Par exemple le fait qu'une page soit en cours d'édition n'est pas commun à toutes les pages, seules certaines le sont peut-être, ce qui est assez restreint.
Par contre dans le modèle que je proposais dans
ActionEtDroitDUtilisation, toutes les actions devraient normalement posséder les propriétés que je leurs donnais (propriétaire, groupe, droits de ceux-ci, des membres, des visiteurs...), il est donc à mon sens préférable d'utiliser une table dans ce cas. --
LordFarquaad
- Pour cet exemple je ne suis pas du tout d'accord. Le nombre d'Actions de WikiNi n'est pas exponentiel ! on peut même considérer que ce nombre est limité ; WikiNi avec plus d'une centaine d'action deviendrait ingérable... -- CharlesNepote
- A mon sens ce n'est pas la quantité d'information qui joue mais plutôt leur "répétition". Par exemple dans un forum de discussions, il n'y a généralement que très peu de sous-forums, pourtant je pense que tous les logiciels/scripts de forums consacrent une table rien que pour les forums. La quantité d'actions dans WikiNi est du même ordre... -- LordFarquaad
Un autre exemple: les membres d'un groupe. Tous les groupes possèdent des membres (ce qui est tout de même le principal objectif des groupes...), ce qui rend préférable l'utilisation d'une table de correspondance groupes-utilisateurs (surtout au niveau des requêtes SQL). Pour ce qui est de données uniques il y a notemment la configuration du wiki, ou encore les éventuelles données (spécifiques, et donc aussi restreint) que pourrait avoir un module (principalement les actions, a priori). Il ne faut pas non plus avoir peur de créer des tables ou de les modifier: ce sont des opérations qui ne présentent pas un grand risque tout de même (surtout créer, et si c'est suffisemment bien conçu, il ne devrait pas y avoir besoin de les modifier). Par ailleurs il est à mon sens toujours préférable d'utiliser peu de requêtes en travaillant sur plusieurs tables que beaucoup de requêtes travaillant sur une table contenant des données de tout type, et des requêts supplémentaires pour récupérer les correspondances dans les autres tables... --
LordFarquaad
Réalisation concrêtes rapides permises par l'usage de triplets
- filtrer les referrers
- filtre anti-spam (conception en cours)
- variables de configuration du coeur (problème déjà discuté)
- horodater la dernière utilisation de la synthèse pour éviter les abus (cf. DiscussionsActionSynthese) (bloquant pour l'intégration de cette action) (1/2 heure de travail)
- horodater l'édition d'une page permettant d'alerter l'éditeur suivant que la page est en train d'être éditée par xx :
De cette manière, le développeur d'action ou de handler
WikiNi peut stocker des données en base sans changer le modèle de
WikiNi. A ce titre, certaines
ContributionsAvancees pourraient ainsi devenir des
ContributionsClesEnMain.
- Pour moi ce qui différencie les ContributionsClesEnMain des ContributionsAvancees c'est uniquement le fait d'avoir à éditer manuellement certains fichiers... S'il s'agit juste d'effectuer une requête pour modifier la structure de la BDD, ça reste du clef en main (surtout qu'il est facile de créer un installeur ou encore d'intégrer l'installation automatique au module). -- LordFarquaad
- Là tu décris le clef en main du développeur... Pour quelqu'un qui n'a qu'une culture d'informatique "bureautique" ou ludique, l'emploi d'un logiciel FTP pour transférer est déjà un petit problème. Je part du principe qu'il a déjà réussi son transfert FTP des fichiers de WikiNi vers son serveur, un transfert supplémentaire ne devrait donc pas lui poser de problème. En revanche : 1. executer un script SQL lui complique beaucoup la tâche ; 2. il n'existe actuellement aucun installeur. Le fait d'avoir une table déjà prète pour l'ajout de nouvelles données améliore donc considérablement les choses : 1. pour le développeur (qui n'a pas à créer d'installeur) et 2. pour l'utilisateur qui peut installer son action facilement. Je veux bien que tu chipotes sur telle ou telle chose mais là, franchement, le gain est quand même évident. -- CharlesNepote
- Pour une action nécessitant de stocker des informations de configuration dans la table des triplets, il y aura tout de même probablement une "installation" à faire: l'insertion de ces données dans la table. Tu diras peut-être qu'il est possible de le faire de manière transparente à la première exécution, mais la création d'une table l'est aussi... -- LordFarquaad
--
CharlesNepote
Syntaxe des triplets
Nous retenons une syntaxe proche de la syntaxe RDF NTriple :
<http://www.wikini.net/wakka.php?wiki=FoRum> <http://wikini.net/_vocabulaire/hasBeenEditedOn> <2004-04-09 23:26:42>
Archives de la discussion
Ne serait-il pas préférable d'utiliser des préfixes tout de même ? par exemple ThisWiki:FoRum, WikiNi:_vocabulaire/hasBeenEditedOn etc. A mon avis, on pourrait non seulement économiser pas mal de place si l'utilisation est forte, mais cela éviterait aussi des risques de doublons (provoqués par exemple par des fautes de frappe) et cela faciliterait le déménagement d'un wiki: si un jour wikini.net devient wikini.org, il serait tout de même contraignant d'avoir à traiter toutes les données pour remplacer "net" en "org" ! --
LordFarquaad
- J'y réfléchi. Voici mes premiers arguments :
- l'utilisation de préfixes ne permet pas d'écrire un code portable : rien ne te garanti que deux gus n'ont pas écrit dans leur coin telle ou telle action utilisant un propriété qu'ils ont défini comme Wiki:page. Il faudra alors réécrire cette action et modifier les données de l'un ou l'autre...
- De fait, par contre le ThisWiki me semble tout de même encore utilisable, mais tu (ou ProgFou) as fait remarquer que cela compliquait le partage et la fusion de données entre plusieurs wiki's, notemment pour les WikiFarm. Deux choses me viennent alors à l'esprit:
- La fusion de données communes à plusieurs wiki's serait quand même quelque chose de réservé aux personnes assez expérimentées. Pour ce qui est des WikiFarm il me semble que la seule solution proposée actuellement pour WikiNi consiste à créer toutes les tables pour chaque wiki, donc pas question de fusion.
- La fusion de données se fera probablement par script interposé, dès lors le script peut traiter les données pour remplacer le ThisWiki par l'url complète correspondante, si nécessaire.
- Par ailleurs j'ai l'impression qu'il s'agit vraiment de cas particuliers difficiles à prévoir et qui dépassent largement l'utilisation classique de WikiNi -- LordFarquaad
- les URLs permettent aux développeurs d'utiliser un identifiant qu'ils maîtrisent ; toi, LordFarquaad, tu pourras utiliser notredomaine.org parce que tu le maîtrise et parce que tu as la légitimité pour le faire
- Oui, de fait, pour les urls externes ça reste apparemment préféréable. -- LordFarquaad
- les fautes de frappes sont un faux argument : il n'est pas question pour un utilisateur, sauf cas exceptionnel de taper lui-même les URLs complètes
- Ce n'était qu'un exemple, difficile à priori d'envisager d'autres cas... Enfin soit -- LordFarquaad
- l'argument de la place occupée me paraît tout à fait négligeable au regard de la place occupée par les centaines (voire les milliers) de versions complètes des pages du wiki ; si tu veux travailler absolument à des économies d'espace, c'est de côté là qu'il faut travailler... tant qu'on aura pas idée de l'utilisation concrète de cette table, il est présomptueux de lui prédire une inflation délirante...
- ... ou le contraire. Note que pour des WikiFarm ça pourrait jouer pas mal, mais relativement à la masse de pages ça reste aussi difficile à prédire... Sinon je pense en effet qu'il serait bon d'envisager une meilleure façon de stocker les pages, mais ça risque de s'avérer compliqué... -- LordFarquaad
- l'argument du changement de domaine est le seul que je retiens ; il devrait pouvoir être traité de manière automatique ; un changement de domaine devrait impliquer une nouvelle installation, et donc une détection de changement et donc un traitement de ce problème de manière automatique (cela ne devrait pas être bien sorcier)
- Oui je pense aussi que c'est le plus important, et que ça reste la priorité. A mon sens un changement d'hébergeur ne doit pas impliquer une nouvelle installation, sachant que la seule utilité est de recréer le fichier wakka.config.php et qu'il faudrait ensuite recopier les tables (un changement d'hébergeur implique toujours de mettre les mains dans le cambuis si l'outil ne propose aucune fonctionnalités permettant de le gérer...). En imaginant que l'utilisateur soit obligé de réeffectuer une installation (actuellement rien ne l'y force...), et qu'il faut en plus que l'installation prenne en charge les changements d'URL dans toute la base de données (récupérée comment ? l'utilisateur doit-il l'avoir restaurée au préalable ou doit-on analyser le fichier contenant les requêtes de reconstruction de la base ?), il me semble que c'est tout de même fichtrement plus compliqué que de modifier les host, database, user et password dans wakka.config.php... -- LordFarquaad
- En conclusion, je continue de penser qu'il s'agit d'une bonne solution. -- CharlesNepote
- Comme je l'ai dit sur jabber, ça ne coûte rien d'essayer, on verra bien ce qu'il est nécessaire ou non de faire. Je suggère tout de même pour ce qui est des urls internes de prévoir une variable définissant le "préfixe", histoire que l'on puisse facilement passer de base_url à, par exemple, "ThisWiki:" ou encore tout autre chose qui pourrait s'avérer nécessaire à l'administrateur. -- LordFarquaad
Ok. Suite à une longue discussion avec
ProgFou et
LordFarquaad dans une salle de discussion Jabber, nous avons convenu :
- de retenir ces propositions à titre expérimental
- de communiquer sur le fait que la réalisation de la table des triplets est expérimentale dans WikiNi 0.5 et sera éventuellement sujette à modifications dans WikiNi 0.6
Je vous propose du code dès que possible.
--
CharlesNepote
Modèle de données SQL
Schéma proche de RAP
http://www.wiwiss.fu-berlin.de/suhl/bizer/rdfapi/database_schema.html
Intérêt du schéma de RAP :
- schéma simple et efficace : la documentation mentionne : RAP uses a denormalized database schema, where all statements are written into a single statement table. We compared the performance of this solution with a normalized layout. Running benchmarks has shown that the denormalized schema was 2-3 times faster than the normalized one. The trade-off between better performance and increased database size was acceptable for medium-sized RDF models.
- schéma prenant en compte la langue des "littéraux" : permet donc de gérer simplement des contenus multilingues
- schéma prenant en compte le type des "littéraux" : permet donc d'effectuer des contrôle sur les données
- schéma prenant en compte la réification en spécifiant le type de sujet ("resource" ou "blank node") : permet de dire quelque chose à propos d'un triplet (par exemple, donner son auteur ou sa date de création) [note : on fera attention à la réification car elle est consommatrice de triplets]
- il devient possible d'utiliser la bibliothèque RAP (très complète) pour importer/exporter des triplets (sans aucune modification du coeur de WikiNi)
- il devient éventuellement possible d'utiliser du code de RAP
Inconvénients :
- la table "namespaces" n'est pas utile
- la table "models" n'est pas utile (?)
Faut-ils donc retenir ce modèle :
- sans les tables "namespaces" et "models"
- sans le champ ModelID? dans la table "statements" ; donc avec les champs :
- subject varchar(255), indexed
- predicate varchar(255), indexed
- object blob, indexed
- l_language varchar(255) only if object is a literal, otherwise NULL
- l_datatype varchar(255) only if object is a literal, otherwise NULL
- subject_is varchar(1) flags whether subject is a resource or blankNode
- object_is varchar(1) flags whether object is a resource, blankNode or literal
In RDF API for PHP V0.9.1 every persistent model (DbModel?) is given a unique URI (modelURI) to differentiate it from other models. Thus, when creating a new DbModel? or retrieving an existing one, we have to specify its modelURI. For example, we can create a new, empty DbModel? in the Access database from the previous section by calling the method getNewModel() on the database object and passing the modelURI as parameter:
$modelURI = "http://somewhere.edu/rap-v-06/tutorial/DbModel1";
$dbModel1 = $access_database->getNewModel($modelURI);
J'ai questionné les développeurs de RAP quant à une éventuelle intégration de leur modèle dans
WikiNi ; voici leurs réponses :
Autres schémas