[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[higgins-dev] Filter capabilities

Do we want/need the filter to be able to specify matches on an attribute's metadata? For example: Find all people where eyeColor has a value of  blue and has a source of http://www.colorado.gov/rmv?
I assume so.  If so, it affects the way the filters are allowed to be constructed.  We may also need to make sure one can present the query above, and distinguish that from this one:
Find all people where eyeColor has a value of  blue and where eyeColor has a source of http://www.colorado.gov/rmv
The two differ in that the second can match when one eyeColor is blue, and another has the colorado rmv source.
A rough idea of a non-SPARQL way of doing these would be:
first: (eyeColor{source=http://www.colorado.gov/rmv}=blue)
second: (eyeColor=blue) & (eyeColor{source=http://www.colorado.gov/rmv})

>>> "Tom Doman" <TDoman@xxxxxxxxxx> 10/4/06 11:04 AM >>>
Let's throw, this is the most important issue for me at the moment.


>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 10/4/2006 10:48 AM >>>
> Do you think what you and Tom have in mind will meet this goal?

I think that would depend on the way we represent an attribute type and/or value assertion (value to be matched).  If we allow (or provide for) an attribute value assertion to reference specific parts of a value (something like either (address.city=provo) or (address=(city=value))).

Again, the data model presented to the consumer via the APIs is this:
Digital Subject has Attribute(s) (name/vals)
Attribute has a name and AttrVal(s)
AttrVal is either simple or complex
Simple AttrVal has simple data
Complex AttrVal is just like a Digital Subject insomuch as it has Attribute(s) (name/vals)

I'd prefer a filter that maps to that model rather than the RDF model (if possible).  In my (probably simplistic) way of looking at things, if the filter format allows one to drill down sufficiently into the model surfaced by the APIs, then either it's sufficient for any Higgins provider's RDF, or our API is itself insufficient.

I could try to throw together a proposed filter interface we could shoot holes into.


>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 10/3/06 9:29 PM >>>

Jim wrote:

I'm wondering if this is another area where "RDFness" is creeping into the abstract APIs too much.  Noting the sample code in http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg00831.html, the API user doesn't really know, or need to know that there's a separation between the Digital Subjects and their attributes -- doesn't know they are represented in RDF as separate statements with relationships tying them together.

In my mind, it would be simpler to represent the same filter like: (homePhone=555-1212).  Talking with Tom, we also wondered about specifying a filter interface.  This would allow a filter to be built up by adding operators and operands.  It could also have a sprintf-like method for convenience.  Ultimately, we would probably add a method which emits a SPARQL filter -- to be used by providers which actually have an RDF store and could use such a thing.  I think we'd want the filter interface to be simple, yet extensible.  For example, support basic common operators (and, or, not, equality, ordering) yet allow other operators to be supported (lexicalMatch, regex, etc.) in the future.

Does this seem reasonable?  If not, is there a compelling reason to use SPARQL at the API level, where SPARQL tends to require a bit of RDF knowledge?

I see where you're going here and I have sympathy for wanting to hide the RDFness and create something clean and convenient.

What you've written forces us to get more explicit about our goals for the query language. One goal I can think of is the need:

to be able to query arbitrarily complex data structures described as OWL Classes and OWL Properties (especially higgins:Attribute sub-classes and higgins:attribute sub-properties) in the context provider's data model

The benefits of our RDF/OWL foundation is that it provides a metamodel (similar to UML) that allows the developer to define whatever data classes they like from the primitives in the metamodel. So we need a query/filter language needs to be able to navigate into the heart of these structures that from Higgins point of view are only known at runtime.

Although LDAP schemas tend to have simple (literal) attribute values, we envision that other kinds of providers might have values that have multiple component parts. 

Do you think what you and Tom have in mind will meet this goal?

>>> Greg Byrd <gbyrd@xxxxxxxx> 10/3/06 11:28 AM >>>
Tom Doman wrote:
> <snip>
> Could you give us an example SPARQL query for your example instance where we select all instances where "homePhone" == "555-1212"?  My main purpose right now is to look at how to convert SPARQL queries into LDAP filters.
> -Tom

I think it would be something like this:

BASE <uri that we're searching>
PREFIX person:
PREFIX higgins:
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
{{?x person:homePhone _:phone}
  {_:phone higgins:normalizedStringSimpleValue
"555-1212"^^xsd:normalizedString }}

higgins-dev mailing list
higgins-dev mailing list