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