Re: Attribute Architecture proposal

We had an extensive discussion of this on the SRW listserv,  I think we agreed
that this is a flaw that should be corrected, a proposal was suggested (to
forward to the ZIG, that allWords, anyWords and adjacentWords be made Comparison
attributes), and then we got distracted, dropped the ball, and no proposal came
out.

I'm soon going to open up the SRW listserv (including the archive)  to public
access, so you can see the discussion.

I need to study your proposal more carefully because on the surface it seems you
want these to be Expansion/interpretation and we thought they should be
Comparison.  In any case, I agree we should correct this.

--Ray


Alan Kent wrote:

> Hi all,
>
> I have put together a proposal page at
>
>     http://www.mds.rmit.edu.au/~ajk/z39.50/attribute-architecture.html
>
> which describes what I believe is the problem with the current AA and
> a possible way to overcome it. Comments welcome!
>
> In a nutshell, I think AllTheseWords, AnyOfTheseWords, and AdjacentWords
> should not be format/structure attributes in the Utility set. They are
> defining *how* to combine the presence of multiple terms in the supplied
> text (AND, OR, PROX). They do not define the semantic format/structure
> of a string.
>
> Put another way, they are not describing that the string contains words,
> but rather what to do if there are multiple words. To make things worse,
> Adjacent words *is* frequently used in examples with complete-value matching,
> not as adjacent words *within* a title. There is no definition of
> Adjacent Words in the spec.
>
> I propose there should be 'word' and 'complete-value' values for
> format/structure with the three boolean connectors put into a new
> attribute type which describes what to do if there are multiple search
> terms supplied in a single query-term.
>
> But read the web page if you are interested.
>
> Alan

Received on Wednesday, 9 July 2003 16:39:30 UTC