Re: Attribute Architecture -- new type?

On Wed, Aug 27, 2003 at 12:48:06PM +0100, Robert Sanderson wrote:
> Is there a combination of comparison and mTB that makes sense apart from 
> equal?
> 
> Comparisons:
> 
>     * Always Matches (Value =1)
>     * Never Matches (Value =2) 
>     * Equal (Value =3)
>     * Less Than (Value =4)
>     * Less Than Or Equal (Value =5)
>     * Greater Than (Value =6)
>     * Greater Than Or Equal (Value =7)
>     * Not Equal (Value =8) 
>     * Contained Within (Value =9)
>     * Relevance Feedback (Value =10)

Its worth noting that other attribute sets can introduce new comparison
operators. I have not checked, but I would assume geospatial operators
such as 'overlaps' 'intersects-with' etc would be comparison operators
where format/structure would have values such as 'point', 'polygon',
'bounding-box'.

> 4-7 are reducable.  Any + greater than ... pick the lowest and 
> send just that. (and other permutations)

Actually, not for me. We support greater than and less than on types
other than numbers (words), where the sort order is defined by the
server. So while I agree that the query is strange and almost certainly
not useful, the client cannot necessarily 'pick the lowest'.
(But surely the human entering the query could!)

> Contained Within is meaningless unless each subterm can be further split 
> down into a range, but that's plausable depending on the format supplied.

Yes, and other geospatial operators I think would fall into the same
category - *if* it was deemed important to support it.

> Okay, so there's more than just equal which is meaningful, and the ones 
> that aren't trivially reducable to a single term could be useful.  I'd buy 
> into the new attribute.

Maybe I should bite off my own tongue, but there is a counter argument
which is as follows.

Adding a new attribute is a major change the to archecture and so should
be avoided. Instead, multi-valued terms are only useful for words to
handle humans entering query terms. Other values should use separate
AND/OR/PROX nodes in the query (different fields on a query form).

With this line of argument, adding any/all/adj in just for words as
a new comparison operator is a sensible and valid way to go.


Which do I favor? From a technical perspective, I favor the the addtion
of a new attribute type. It seems clean, orthogonal, extensible, etc.
I think it makes implementation cleaner too. From a "management"
perspective, adding in a new attribute type means more extensive and
radical changes to the AA, which may be perceived to be a bad thing and
give negative connotations about the AA. "It keeps changing and growing."

Put another way, I think the former (new attribute type) is a good long
term solution, and the latter (all/any/adj words as comparison) is a good
short term solution.

Maybe another way of choseing is to look at which fits in with CQL better.
CQL says "any" is a relation. With a new attribute type, I guess this
would map to an attribute list of comparsion=equals+multiTerm=any.
CQL "exact" would be an attribute list of comparison=equals+format=string (?).

Alan

Received on Thursday, 28 August 2003 20:09:22 UTC