> Date: Thu, 3 Jun 2004 18:52:54 +0100
> From: Robert Sanderson <[log in to unmask]>
> First draft is available at:
> Comments, as always, are sought :)
Hi, Rob. I don't know much about relevance so I'll just pick on the
document itself. Hope this is useful.
> The default ordering of a result set is left up to the server,
> including no ordering what-so-ever.
"whatsoever" is all one word.
> However, for sophisticated relevance based ranking, this needs to be
> part of the query itself so that boolean operands might be treated
> differently, and how the sub-results of each operand are combined.
I can't parse the last clause.
> If you wish to have an algorithm added [...]
"... to this set ..."
> If the 'relevant' relation modifier from the cql context set is
> given, but no named algorithm, then the server should continue to
> use the basic semantics -- the server may decide which algorithm to
Isn't that a contradiction?
> Also, please note that all aspects of context sets are case
> insensitive. "rel.CORI" and "rel.cori" are to be treated the
Is this generally true of CQL indexes and modifiers?
Why "relevancY" instead of "relevancE"?
> const_* A named constant relevant to the algorithm, eg const_k=0.7
I think you need to say more about this.
What about TF-IDF?
You should probably explicitly say that the set defines no indexes.
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ Cab driver to Groucho Marx: "Have a nice day"; Marx: "I'll
have the hell sort of day I want"
Listen to free demos of soundtrack music for film, TV and radio