Re: Intelligent Rating Systems

  >I might be reading it all wrong, but this looks like a scheme which
  >would entail an awful lot of overhead.  Are you suggesting a scheme
  >where a client would be required to do two retrievals for every
  >document or object retrieved (one to an independent rating server and
  >a second one for the document)?  
 
Yes, two separate retrievals, and not only two, but one (for the
document retrieval) plus n other requests to n meta information
servers which serve m rating topics (m>=n).  And they are all
concurrently, so "overhead" is relative here to the slowest server;
given the current http protocol which sends out a separate request for
every inlined gif etc. this is not bad at all, and, indeed,
experiments with our prototype implementation show that it is hardly
noticeable.  Note that once you queried a meta info server, this
server would also reply with a list of rated sites (if sufficiently
small), and this information would then be used by the client to avoid
sending out additional queries for ratings to sites which are not
rated. This caching info saves a lot of queries (because it exploits
locality which can be generally found).

  >This also suggests that, as is the
  >case with commerce protocols like iKP and its ilk, we'd need a new and
  >distinct "content-rating" protocol.

Yup, a protocol layered on top of http or integrated into it which is
of the type of the one in http://www-diglib.stanford.edu/COMMENTOR/.
(Since this is more than half a year old, it might not qualify as new,
but anyway...;-)

  >I'll stick by the notion that rating information should come back to
  >the client from the server encoded in an HTTP header line.  The server's
  >rating could optionally be verified at its source, assuming it
  >contains enough information to identify the source.  This preserves
  >the option of checking a URL or URI with a third-party rating service
  >*before* retrieving the corresponding document from a server, but if
  >you're willing to trust a server's rating estimates the extra step
  >isn't necessary.

You cannot assume that a content provider will be willing to carry
ratings by others.  For example, if someone does not like Compaq PCs
and makes bad rating annotations for their pages, then I doubt that
Compaq will agree to use their resources to serve this type of
information to people.  Still, consumers who wish to see these and
other comsumer report type annotations can select the appropriate
topics ("PC product ratings by Joe Doe") and will be able to see them.
Rating information depends on perspective of the rater; it is owned by
authorities which will in general be distinct from the owners of the
underlying document; access control might be set differently for
ratings (for example, if a rating service wants to charge for the
ratings); etc.  Unless you want a hack, this all requires that you
need to separate them out architecturally.

Note also that you get a lot of administrative advantages by
localizing ratings on a particular topic ("set") in one server, and
not spreading them out over all content servers rated with respect to
a topic.

  >How to derive and encode content ratings and the semantics of content
  >ratings shouldn't become embedded in a content-rating syntax, which
  >needs to be kept simple, securable and extensible.  For the sake of
  >the discussion, I'll suggest a strawman two- or three-field header
  >defined:

Yes, it does not make sense to predefine a certain scale since there
are too many different unanticipated usages.  The topic set for the
ratings (we called it often "set") should be able to define both a
scale of ratings, and a certain set of actions (like "pop up window
with the following text", "do not display original document", etc.---a
few ones will suffice here).

Cheers, - RMR

Received on Monday, 26 June 1995 21:29:42 UTC