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

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