On Wed, 2 Jun 2004, Mike Taylor wrote:
> > From: Robert Sanderson <[log in to unmask]>
> > dc.title any/rel.algorithm=cori "fish squirrel"
> > and/rel.combine=mean
> > dc.author any/rel.algorithm=lr/rel.constant1=0.705 "sanderson taylor"
> > This would thus need to be in the ZeeRex record somewhere.
> Why? This looks to me like the kind of thing that belongs firmly in a
> CQL context set definition, just as the description of how to
Perhaps it is just the same, but here's my rationale.
In order to get a new algorithm registered, they would need to contact me
and have me add it to the context set. Which is the same problem as we've
resolved using URI identifiers in the understanding that enforced
registration is bad, mmkay.
The other option is to have everyone define their own algorithms in their
own context sets and not have a single relevancy set at all. Which isn't
as bad as it might be, but isn't very appealing either.
Instead of rel.algorithm=cori, it would be foo_rel.cori, c3_rel.lr,
etcetc. The 'common' algorithms could be collected into one set and
additional ones put into new sets or into the main one, but selecting
'common' algorithms is much the same as dipping your hand into a hat and
pulling out folded pieces of paper.
> What am I missing? Specifically, what new and useful action could a
> ZeeRex-configured client automatically take if we added the
> information you're talking about?
Without the explain section, how can you know which relevancy algorithms
are supported at all without just trying them? And there's a fair few
published algorithms, and a metric truck-load of unpublished ones, I'll
bet.
If we have this problem for relevancy ranking algorithms, they'll show up
elsewhere as well I'm sure.
Rob
--
,'/:. Dr Robert Sanderson ([log in to unmask])
,'-/::::. http://www.o-r-g.org/~azaroth/
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. University of Liverpool
____/:::::::::::::.
I L L U M I N A T I L5R Shop: http://www.cardsnotwords.com/
|
