review-brainstorming-fr

Review Brainstorming

Il y a eu plusieurs efforts pour définir les formats de données pour poster des "reviews" (critiques) de produits, services, etc. sur le Web.

Cette page sert à documenter le brainstorming et les idées résultant de l'analyse d'exemples de critiques à partir de sites du vrai monde pour le design d'un microformat pour les critiques simples. -Tantek

Contributeurs

Copié à partir de review-fromats qui lui-même était contributé à partir du Wiki des Développeurs de Technorati : ReviewsFormats)

• Tantek Çelik
• Niall Kennedy

(traduction française en cours Christophe Ducamp)

Voir aussi

• exemples de critiques
• formtas de critiques
• hReview

Idées sur un Microformat pour une critique

Les idées vers un simple sous-ensemble microformat des efforts précédents, suffisantes pour exprimer le 80/20 des exemples de critiques du vrai monde sur le Web.

Champs communs de critique

• item
  • optionnel : type d'item (business, Web page/site, produit, événement, personne, endroit, fichier, texte)
  • nom/titre de l'item étant critiqué (string | ["hCard"] si business ou personne)
    • optionnel : URL (toute information supplémentaire devrait être quelque part ailleurs, pas dans la critique elle-même)
    • optionnel : image (URL)
• auteur (["hCard"]|nom|email|URL)
• date publicaton critique/date rédaction (ISO8601 datetime)
• notation de 1 à 5 (valeurs par défaut max = 5, valeur par défaut min = 1)
• optionnel :tags (mot-clé,notation)*
• optionnel : commentaires (string)

Voir hReview pour le résultat et l'évolution de ces idées sur un microformat.

idées hReview 0.3

Cette itération de hReview est directement en réponse à hreview-feedback et aux problématiques hReview. Voir ces documents pour plus de détails.

Modifications à partir de hReview 0.2:

• DOIT (au lieu de DEVRAIT) utiliser hCard pour la description de l'item ou d'un business
• modifications reviewer
  • rend le reviewer *optionnel* par un feedback venant de Ryan King et Mark Nottingham
  • Si l'auteur est absent de la hReview, alors regardez en dehors de la hReview, dans le contexte de la page, pour l'auteur "reviewer". S'il n'y a pas de "reviewer" en dehors, utiliser alors <address> pour la page.
  • DOIT (au lieu de DEVRAIT) utiliser hCard pour représenter l'information de l'auteur
• DEVRAIT utiliser hCalendar pour représenter un item de 'type' 'event'
  • Accepté. Nous avons étudié le fait de faire de cela un MUST, et l'avons repoussé à la prochaine version, en se fondant sur l'expérience de publication avec la 0.3
• ajouté un chiffre décimal après la virgule pour la précision des valeurs numériques des 'ratings'
• utiliser [[hcard-fr#Extraction_de_Valeur|la "value" construite à partir de la hCard] (comme elle est utilisée dans les propriétés "tel" par exemple) pour baliser plus explicitement la valeur de notation quand elle fournit aussi (balisage) le best/worst d'un rating. besoin de fournir aussi une exemple qui produit ça.
• ajout rel-license pour indiquer la licence de la hReview en tant qu'ensemble.
  • ajouter ça tout aussi bien à hatom !
• permettre les tags dans les ratings pour annoncer les tags évalués, la même chose que les ratings dans les tags selon la suggestion de Eran Globen.
• ajout support include-pattern pour permettre plusieurs critiques pour le même items afin de ne pas répéter l'info item.

Amélioration Informatives :

• Notez que les tags scalaires/rated utiliseraient idéalement un espace tag qui explique les notations pour ce tag. par ex. que veut dire Food:18/30 ?