Re: [higgins-dev] Filters, Comparators, and Model (Schema)

["Tom Doman" <TDoman@xxxxxxxxxx>]

So, the data type of the value in each substring comparison component would be dictated by the schema for the attribute being searched?  I guess this could apply equally to all comparators, substring or otherwise, if we are ok with restricting the comparison data type to a single type.  I think I'm good with that ... can anyone think of a case where we'd want to be able to compare an attribute as say, a string OR a number?

Tom

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 01/19/07 2:04 PM >>>
Here's what I was thinking on #2 below:
 
for this example, I'm going to show how we can build up a substring assertion filter.  Note that this substring assertion wouldn't necessarily be applicable only to string types, the word "substring" is really meant to mean "sub part".
 
To refresh the discussion, the need for this matching rule is so we can search for subjects who have an attribute like "surname" that has as a value something that begins with "j", contains "ns", and ends with "n".  (Note, change "surname" in this example to whatever it's fully qualified name is -- I'm too lazy to look it up)
 
To solve this, we only need to say that the substring matching assertion for the "surname" attribute is backed by ab assertion value which is complex, rather than simple, and then define the semantics for it.  It could be done like this:
 
assertion (this could be a BasicFilterAttributeAssertion)
assertion.comparator is set to IFilterPropertyAssertion.COMP_PROP_SUBSTR
assertion.type is set to "surname"
assertion.value is an instance of SubstringPropertyAssertionValue (see below)

class SubstringPropertyAssertionValue implements IComplexValue
type is set to "substringPropertyAssertion" (with some namespace)
props could contain: {instance of SubstringBeginsWithProperty, instance of SubstringContainsProperty, instance of SubstringEndsWithProperty}

class SubstringBeginsWithProperty implements IProperty
type is set to "substringBeginsWith" (with some namespace)
value is an instance of SubstringBeginsWithSimpleValue

class SubstringBeginsWithSimpleValue implements IPropertyValue
type is set to the same thing as the type for the property being searched (in this case "surname")
isSimple = true (same as for the surname property)
data is set to the same thing one would set in a surname property value.  In this case a BasicStringSimple value set to "j"

Same kind of deal for contains and endswith

I can code this up and send out sample javadoc it that would help

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 
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev