Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Filters, Comparators, and Model (Schema)

Just coming back to this after a few months gave me fresh eyes.  This comes down to two general issues:  #'s 1 and 3 have to do with Advertisement/discovery, and #2 requires the ability to express filter assertions which may differ from the attribute values themselves.
 
re-looking at things, we can already do #2 with the existing interfaces -- I just worked it out on paper, and will try to explain it in a followup message.
 
For #'s 1 and 3, we've thought about adding this extra information to the org.eclipse.higgins.idas.model interfaces (and perhaps the Higgins OWL as well).
 
 
OTOH... for sometime now, I've been wondering how it would look/feel to move all of the factory-type methods (i.e. creation of new DigitalSubjects, Properties, Property values, Filter Assertions, etc.) into the org.eclipse.higgins.idas.model package.  I'm not exactly sure how it would all fall out, and I suspect it could take a couple days or more to come up with a clean model.   I'll send further thoughts on this in yet another email.
 
Jim

>>> "Tom Doman" <TDoman@xxxxxxxxxx> 11/7/06 4:57 PM >>>
Lately, I've been looking at implementing a string format for filters for use by one of our bandit components.  As I started into that, I've discussed with Jim some of the unresolved issues surrounding Filters in IdAS.  The main issue surrounds what we've called comparators in IdAS.  The interface we have right now has several issues:

1. It requires compile time knowledge of what kinds of comparators and comparators themselves are allowed and used for a given attribute type.
2. There is no way to accommodate complex comparators which require more than just a single assertion value.
3. There is no way to determine the format required for an assertion value that goes with a given comparator.

Many times, we make assumptions on all of these that work out fine.  Anyway, after discussing this with Jim, we are starting to believe that the best way to rectify this is require attribute model definitions to specify what the kinds of comparators they support (ie. Equality, Ordering, Substring, etc.), the actual comparator used, and the assertion value format.  Then, at run time, the IdAS consumer may query this information to properly build filters.  This could possibly just be an extension of Valery's model work, though neither Jim nor I are sure what all the interfaces represent there.

I want to try to put out some examples but I wanted to see if anyone else has given this area some thought and has any comments or suggestions.

-Tom

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

Back to the top