Difference between revisions of "Taxonomy issues"

From Project VRM
Jump to navigation Jump to search
m (Reverted edits by KruGer (Talk) to last version by Whitneymcn)
Line 13: Line 13:
  
 
Suggests the desirability of a parallel reputation system that covers both vendors and seekers.  Consider how long an entity has had a public presence, RFP/feedback patterns.  Unfortunately seems to also suggest that there could be an actual need for some third-part(y|ies), handling the seeker/vendor DB stuff outlined in the VRM diagram:  in addition to pointers to requests/offers, the archive retains history.  In this case I guess one would want as many competing versions as possible, so that clients can poll multiple and use their own systems to resolve differing data.
 
Suggests the desirability of a parallel reputation system that covers both vendors and seekers.  Consider how long an entity has had a public presence, RFP/feedback patterns.  Unfortunately seems to also suggest that there could be an actual need for some third-part(y|ies), handling the seeker/vendor DB stuff outlined in the VRM diagram:  in addition to pointers to requests/offers, the archive retains history.  In this case I guess one would want as many competing versions as possible, so that clients can poll multiple and use their own systems to resolve differing data.
[http://www.sexalemi.org sikis izle]
 
[http://www.pornositeleri.net porno izle]
 
[http://www.sexalemi.org sex izle]
 
[http://www.sexalemi.org sikis]
 
[http://www.cinsel.name sikis izle]
 
[http://www.cinsel.name.tr sikis]
 
[http://www.hiphopalemi.net hiphop]
 
[http://www.kelebekchat.net kelebek chat]
 
[http://www.kelebeksohbet.org kelebek sohbet]
 
[http://www.chatsohbet.org chat sohbet]
 
[http://www.siberchat.net chat]
 
[http://www.pornositeleri.net porno]
 
[http://www.pornositeleri.org porno izle]
 
[http://www.pornositeleri.org porno siteleri]
 
[http://www.sexpormok.net sex]
 
[http://www.mynetsohbet.net mynet sohbet]
 
[http://www.hiphopalemi.net chat]
 
[http://www.hiphopalemi.net rap]
 
[http://www.kelebekchat.net kelebek]
 
[http://www.gaychat.gen.tr gay chat]
 
[http://www.sempatim.net sevişme]
 
[http://www.cinsel-sohbet.com cinsel sohbet]
 

Revision as of 08:36, 1 December 2009

Very much a stub...sorry for the current "stream of consciousness" character of this -- will be cleaning it all up as soon as possible.

There's a lot of work here. RFPs should allow for widely varying degrees of specificity. Ideally, a seeker should be able to create an RFP for:

  • a blackberry 7130c
  • a cell phone with bluetooth and EDGE support
  • a cell phone costing less than $250
  • a cell phone

Even before considering the different attributes required by different types of requests (travel planning vs. product purchase, for example) it's clear that creating a workable microformat for RFPs will be a fascinating (and frustrating) process. It's worth noting, though, that work in this area pays off in many ways.

Desirable: RFP attribute "package," optional, linking multiple RFPs. Indicator to vendors that the seeker is interested in the entire package (implicitly asserting that offers that cover the entire package are preferable/required? Or explicit flag?) -- plane ticket RFP, car rental RFP, hotel RFP, linked by package ID. Five different books, linked by package ID. Possibly worthwhile on both ends: seeker only wants A if they can also get B, vendor can tailor offer/discounts based on total package.

Note to self: Marti's "fulfillment" RFP attribute is an elegant addition. Does seem to suggest that authoritative, verifiable identity for vendors goes from "extremely useful" to "non-negotiable," though. Note also that it makes authoritative seeker identity even more significant: if seekers provide feedback that (is | may be) used to establish vendor reputation as an evaluation factor, there's significant incentive to astroturf.

Suggests the desirability of a parallel reputation system that covers both vendors and seekers. Consider how long an entity has had a public presence, RFP/feedback patterns. Unfortunately seems to also suggest that there could be an actual need for some third-part(y|ies), handling the seeker/vendor DB stuff outlined in the VRM diagram: in addition to pointers to requests/offers, the archive retains history. In this case I guess one would want as many competing versions as possible, so that clients can poll multiple and use their own systems to resolve differing data.