| Re: [higgins-dev] Filters, Comparators, and Model (Schema) |
|
Here are my initial thoughts on the OTOH section below:
First a quick rundown from IdAS consumer's POV: You want to create a person Digital Subject and populate it's email address. You get the context's model (IContextModel) and discover that one of the IDigitalSubjectModels returned by getSubjects() has a type of "...#person". Further, you find that this IDigitalSubjectModel has an IAttributeModel for the "...#email" attribute. Using the IAttributeModel, you get an IAttributeValueModel which allows you to create an IAttributeValue instance. Similarly, using the IAttributeModel and IDigitalSubjectModel, you create IAttribute and IDigitalSubject instances respectively. You call the appropriate add() methods until you have an instance of IDigitalSubject which is ready to be added to the context.
So far, this isn't much different from calling the various create() and add() methods in the org.eclipse.higgins.idas package (the difference being that things were discovered along the way). Where we start to see a benefit is in update and filter-based operations. When updating a DS, one may or may not have already read the DS. If not, there are no create methods on IContext for Attributes and their values. Similarly, when creating a filter, the IdAS consumer doesn't yet have the DS being searched for, thus has no create methods for the attribute assertions needed to create the filter.
Has anyone else had similar thoughts? Anyone like/dislike moving in that direction?
Jim
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 1/12/07 2:16 PM >>> 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 |