[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Updated example ontologies

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?

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