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
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:
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?