| Re: [higgins-dev] String format for filters |
|
So, let's pretend we like prefix notation for all (logical op's and comparators). It was looking fine until I realized we need assertions for non-attribute members.
Unless there's some fancy way of making assertions for the other members look similar to attribute assertions, I think we'll need a way of making obvious the type of assertion. Something like this:
<Assume the following tags represent assertions for their related DS members>
@T type
@I CUID
@A Attribute
@M Metadata
@R Relationship
"(@I,urn:mary)"
could be used to find the subject named "urn:mary". This assumes we limit ourselves to only performing equality matches on the name. Otherwise, change it to "(@I,=,urn:mary)". Will there be the need to find subjects with an asserted prefix such that "(@I,beginsWith,urn:Tom)" matches for "urn:Tom Doman" and "urn:Tom Edison"?
"&&(@T,pwa:Person)(@A,=,pwa:firstname,Mary)"
could be used to find subjects which are of type person, and have a firstname of "Mary". Again, this one assumes we don't need comparators for the type. I can imagine one wanting to differentiate between an absolute type match and one which matches for the specified type or any sub-type -- so maybe that needs a comparator spot as well.
Looking at the example above, I remember that an attribute assertion can further qualify the attribute type by also specifying a sub-filter for metadata on the attribute.
"(@A,=,(pwa:firstname,(@M,=,higgins:lastModified,20061010Z)),Mary)" should find subjects where the firstname attribute was lastModified on 10/10/2006 and has a value of "Mary".
A Metadata filter item could look like the one embedded above (extracted here):
"(@M,=,higgins:lastModified,20061010Z)"
A Relationship filter item could look like one of these:
"(@R,*,urn:ParentOf)" matches for all subjects having a "ParentOf" relationship to anything (I used * as shorthand for "present") "(@R,=,urn:ParentOf,{urn:myContext,urn:mary})" matches for subjects which are the parent of urn:mary. Note that this filter had to use {} to enclose the DigitalSubjectRef's contextID/CUID pair."(@R,impliedEquals,urn:ParentOf,{urn:myContext,urn:mary})" matches for subjects which are the parent of urn:mary whether due to having the parentOf mary relationship or due to there being a childOf relationship on mary pointing to that subject. (This is just an example of how a special comparator could be used to allow inferred matches to happen).
I think complex attributes could be represented/parsed as well.
"(@A,equalsFieldsOf,pwa:postalAddress,{{pwa:city,Provo}{pwa:state,Utah}})" would find subjects who live in Provo, Utah. Would we need to search for subjects where the state is Utah, but the city starts with "P"? If so, I'd have allow sub-filters inside attribute assertions. Note that you can't do it like this:
"&&(@A,equalsFieldsOf,pwa:postalAddress,{{pwa:state,Utah}})(@A,startsWithFieldsOf,pwa:postalAddress,{{pwa:city,Provo}})" because that will match when a person has two addresses where one has state=Utah and the other has city=Provo
Jim
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 10/11/06 4:38 PM >>> Here's an excerpt from an IRC session earlier today:
(11:35:47 AM) Jimse: For IdAS filters, I'd like to specify a string format people can use, and then build a parser which will produce the proper IFilter from any string-filter (11:36:00 AM) Jimse: I prefer to use prefix notation rather than postfix notation (11:36:14 AM) Duane: Yes Please. (11:36:18 AM) tdoman: sounds good to me (11:36:19 AM) Jimse: at least for the logical operators (11:37:31 AM) Jimse: prefix for logical only "||(color=blue)(color=violet)" (11:38:27 AM) Jimse: prefix for logical and comparators: "||(=,color,blue)(=,color,violet)" (11:38:56 AM) Jimse: infix for both: "(color=blue)||(color=violet)" (11:39:26 AM) Jimse: prefix for logical let's me do this: "||(color=blue)(color=violet)(color=purple)" (11:39:41 AM) tdoman: if we're going to do comparators that way, we might as well start a string rep.; (11:39:51 AM) tdoman: (color,violet,equal) (11:40:03 AM) Jimse: sure, these are just examples (11:40:12 AM) Jimse: in reality, the identifiers would be URIs (11:40:27 AM) Jimse: comparitors would be too (11:40:33 AM) tdoman: in the string representation? (11:40:36 AM) tdoman: yuck! (11:40:41 AM) Jimse: with maybe a couple shortcut comparators (11:41:03 AM) Jimse: but... I also want to do a sprintf-style string rep (11:41:09 AM) Duane: please || makes more sense than urn:higgins:idas:comparators:or (11:42:35 AM) Jimse: "||(color,%a,%c)(color,%a,%c)", <assertion1>, <eq_comparator>, <assertion2>, <eq_comparator> (11:43:46 AM) Jimse: I think we'd only need: %a for ass ertions, %c for comparators, %a for attribute identifiers (11:44:02 AM) Jimse: I suppose we could do %l for logical operators |