listing-brainstorming-fr

From Microformats Wiki
Revision as of 17:34, 6 November 2006 by ChristopheDucamp (talk | contribs) (traduction en cours à relire)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Brainstorming Annonces Classées

Quelques idées de départ

  • Le format devrait être à son point le plus basique être facilement mis en oeuvre par les sites actuels de petites annonces sans avoir à modifier leurs installations existantes (par ex : les remplir avec leurs SQL).Par exemple : http://www.villagevoice.com/classifieds/index.php?page=ads&category=Employment&sort=1&database=0&a=0&class=4025 a une structure de données très simple, on peut imaginer cette structure de données simple provenant d'une base de données SQL. S'ils ont besoin d'altérer leur SQL pour s'adapter au microformat, il ne sera pas adopté (ou au moins pas rapidement). Idéalement tout ce que cela prendrait pour les sites actuels pour l'adopter serait simplement un redesign.
  • Le format devrait être suffisamment expansible pour permettre à des données spécifiques d'être extraites de lui de façon que les services spécialisés (agrégateurs de formats spécifiques, agrégateurs sociaux, filtrage collaboratif, agents de découverte) pourraient être construits dessus.
  • Le format devrait être assez flexible pour être ajouté facilement aux systèmes actuels de CMS et de blogs.
  • Le format devrait être assez flexible pour ne pas inteférer avec les business models existants des sites stabilisés de petites annonces. Par exemple, un site d'annonces d'emplois peut tirer des revenus des commissions sur les prospects trouvés et contractualisés via leurs sites. Si le moyen véritable de contacter le prospect est requis dans le format (plutôt qu'un lien vers la véritable annonce sur son site), ils pourraient être dépités de mettre en oeuvre le microformat (parce que ce la sortirait de la boucle pour ainsi dire). Un argument similaire pourrait être produit pour d'autres types d'annonces classées. Néanmoins s'ils peuvent implémenter une simple structure de données qui peuvent être ensuite tracées vers leurs sites, ils le mettraient probablement en oeuvre parce que cela aiderait dans le processus de découverte de leurs annonces classées (à travers les agrégateurs ou crawlers).

Une Structure de Données Basique

  • A leurs niveaux le plus basiques les schémas de P.A. basés sur le web pourraient se réduire à :
    • nom de l'item
    • description (Quelques sites ne semblent même pas avoir un Titre)
    • date annonce
    • contact info. (hCard pourrait être utilisé pour ça)
  • Info Contextuel ou Implicite.
    • Eu égard aux véritables schémas qui peuvent être extraits des pages html il existe quelque information qui est implicite soit contextuellement ou par la navigation dans tous les exemples trouvés. Par exemple :
      • Une annonce sur ebay.de implique ( contextuallement ) que le véritable endroit de l'annonce en elle-même est situé dans le pays Allemange. Autres exemples : paris.craiglists.org, une annonce classée sur nytimes.com ou (NY) globo.com.br (Brésil) ou www.timeout.com (Londres).
      • Une catégorie ou "Type" d'annonce en elle-même est généralement implicite par la navigation dans les sites. Par exemple, en accédant accesing craiglist.org on choisit le type d'annonces qu'on veut voir ( housing > housing wanted ). Quelques sites ont des structures spécialisées de données dépendantes du type d'annonce (par exemple, il est très commun pour les véhicules en vente d'avoir un champ pour la marque, le modèle et l'année.)
    • Ceci suggère que l'endroit et le type devraient être compris dans le format de base. (Decider ça peut être tout à fait embêtant. Particulièrement les types, parce que les lieux peuvent être extraits à partir du contact.)

Epancher la Structure de Base par Type d'Annonces

  • Une fois un format basique décidé, il pourrait être étendu à des types de structures de données plus spécifiques.
    • Type A vendre
      • Base
        • Le titre pourrait correspondre au nom du produit. (Cette correspondance est juste une idée, mais cela semble être très commun).
        • description pourrait correspondre à la description du produit.
        • catégorie produit (peut faire partie du format basique catégorie. Pas d'idée comment avancer là dessus.)
        • condition du produit (Occasion|Neuf)
      • Optionnel
        • montant prix
        • devise du prix (la devise est soit spécifiée ou implicite contextuellement au moment de nommer un Prix. Un prix pourrait être considéré comme un montant spécifique d'une devise spécifique.)
        • photo (Option, pourrait y en avoir plus d'une *)
        • durée ou date d'expiration de l'offre.
        • disponibilité (S'il y en a plus d'un à vendre, ou même pas du tout)
    • Type A vendre, Catégorie Produit = véhicule (Peut s'étendre à la vente)
      • marque
      • modèle
      • année
    • Type Désiré
      • titre pourrait correspondre au nom du produit.
      • description pourrait correspondre à la description produit
      • durée ou date d'expiration
    • Type Annonce Offre Emploi
      • titre pourrait correspondre à la catégorie de job (semble être une pratique commune)
      • description pourrait corresopndre à la description de poste
      • exigences
      • type de contra (part time| full time | temp)
      • contact pourrait correspondre à la société ou au recruteur
  • Des types plus étendus devraient être imaginés...

Voir aussi