Existe-t-il des tentatives de normaliser les descriptions de tables des logiciels de blogs et CMS, au moins en ce qui concerne la descriptions des articles ?
Ce serait bien pratique de pouvoir dire "je vous installe tel logiciel, mais il sera toujours possible de migrer vers tel autre".
# Ben...
Posté par romain . Évalué à 5.
- une collection d'objets (le plus généralement des articles),
- une collection de commentaires sur ces objets,
- une collection de catégories,
- et du logiciel autour.
La description des objets est parfaitement libre. Maintenant, pour un blog texte classique, l'objet fréquent, c'est l'article :
- un identifiant unique,
- une url unique persistante,
- un titre,
- une description,
- un contenu,
- une date de création,
- une date de mise à jour,
- un ou plusieurs auteurs (un auteur, c'est un nom, un email, + des données au choix).
Maintenant, il y a tellement de façons différentes d'articuler ce type de données (par exemple, prendre en charge un historique complet de toutes les versions de l'article, ou bien ne pas le prendre en charge)...
# Je suis contre
Posté par dinomasque . Évalué à 3.
SPIP dit que c'est un titre, un sous-titre, un chapeau, un contenu, etc.
D'autres CMS ont une conception légèrement différente.
D'autres CMS (Lodel par exemple) n'imposent pas leur définition et proposent de définir un modèle éditorial (liste de types de "documents" à publier et de leurs champs respectifs).
La valeur ajoutée de chaque CMS vient de la façon qu'il a de structurer et de gérer l'information. Imposer un socle commun leur ferait à mon avis perdre beaucoup d'intérêt car ils les empêcheraient de remplir les besoins pour lesquels ils ont été conçus.
Imposer un meta-modèle de données à la Lodel à un CMS simple et rapide comme SPIP n'aurait aucun intérêt. Impoer un modèle de donnée standard et figé à Lodel n'aurait aucun intérêt.
Je crois qu'une solution envisageable serait de concevoir une DTD XML (ou d'en réutiliser une comme TEI) suffisament vaste pour englober tous les besoins.
Le problème ne serait pas pour autant résolu :
- comment un CMS doit-il regrouper des informations dans un seul champ de sa base ?
- que faire des informations du document XML qui n'ont pas leur place dans le modèle de donnée du CMS ?
- comment résoudre la perte d'information d'un document importé puis exporté par un CMS donné ?
BeOS le faisait il y a 20 ans !
[^] # Re: Je suis contre
Posté par Damien Metzler . Évalué à 2.
La base de données sert à stocker des données (et oui). Le logiciel utilise le formalisme qu'il veut. On peut par exemple stocker des données dans un fichier texte, un stream ou encore autre chose....
Le but d'uniformiser les données serait de pouvoir facilement changer de "moteur". Cela passe pour moi par une couche d'abstraction logicielle. Mais celle-ci va être coton à imaginer : il va falloir penser à une API complète permettant de répondre aux besoins de chaque CMS....
Après chaque CMS implémente l'API comme il veut et je peux facilement plugger la partie graphique de telle CMS avec la partie stockage d'un autre..... En tout cas bonne chance pour essayer de normaliser tout ça !
[^] # La valeur de l'information
Posté par _p4_ . Évalué à 1.
Le besoin d'une normalisation à une échelle sémantique se fait sentir pour nous qui manipulons des informations sur le web. Qu'il y ait des normes qui disent un article c'est ça, un fil de news c'est ça (rss?), une liste de liens classés c'est ça, etc (1).. La description de l'information repose sur son sens, et non sur sa formalisation: décrire un type de table n'a d'intérêt que pour une base de données relationelle, pas pour une base objets.
Des dialectes xml utilisant rdf pourraient peut-être exprimer des normes de ce type?
Les normes réduisent le temps de traitement de l'information et augmentent sa compréhension, la perception de son sens, sa valeur. L'information coûte moins cher à produire et à gérer si elle est normalisée.
(1) Exemple: DOAP: décrit qu'est ce qu'un projet: "vocabulaire RDF de description de projet" http://www.doap-fr.org/(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.