> Date: Wed, 2 Jun 2004 21:07:23 +0100
> From: Robert Sanderson <[log in to unmask]>
>
> 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.
Yes, enforced registration is bad. That's precisely why we let people
define things in context sets associated with their own URIs and do
not have a central registry of such sets. This is a problem that we
have solved.
> 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.
It appeals to me. Isn't this a perfect example of the kind of
scenario we invented URI-identification of context sets to solve?
> 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 [...]
Yes.
> [...] but selecting 'common' algorithms is much the same as dipping
> your hand into a hat and pulling out folded pieces of paper.
It is exactly analogous to the problem of identifying common indexes
for searching, but in a much smaller (hence easier to research) space
than that of possible indexes. Anyone wanting to create a socially
responsible context set already has a responsibility to find out
whether any of the elements he wants to include have already been
defined elsewhere; that's always been true and always will be so long
as we want to avoid duplication. Exactly the same responsibility
applies to relevance and merge algorithms as to indexes.
> > 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?
<supports type="relationModifier">rel.algorithm</supports>
<supports type="booleanModifier">rel.combine</supports>
_/|_ _______________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ "The most important thing a father can do for his children
is to love their mother" -- Theodore Hesburgh.
--
Listen to free demos of soundtrack music for film, TV and radio
http://www.pipedreaming.org.uk/soundtrack/
|