Skip to content

Further development of owlet

Jim Balhoff edited this page Feb 28, 2014 · 11 revisions

Owlet is currently working well as a triplestore-agnostic means to use rich DL query semantics within regular SPARQL queries. It can combine any OWL API-based reasoner with any standard SPARQL endpoint. However there are a few ways it could be improved or extended.

Alternative approaches

  • SPARQL preprocessor API (current implementation)
    • Currently owlet provides an API which allows you to transform a SPARQL query containing an embedded OWL expression into another SPARQL query with an embedded FILTER statement. Your application provides the reasoner and chooses what to do with the processed query. This approach seems to preclude the possibility of variables within the OWL expression and thus prevents queries of the OWL model itself.
  • SPARQL endpoint over an OWL API reasoner
    • A version of owlet could be implemented that used DL queries, to a provided OWL API reasoner, to fully answer SPARQL queries. This version would still make use of the convenient embedded class expression syntax. Such a SPARQL endpoint would not scale in comparison to a "real" RDF triplestore. Instead, this owlet endpoint could be queried as a remote SERVICE endpoint from within a SPARQL query to another triplestore. Only the patterns that were best handled by the OWL reasoner would be placed within the SERVICE clause.
    • Since the results would be returned to the calling SPARQL endpoint as value bindings (rather than by generating a FILTER), this would open the possibility of supporting variables within the OWL expressions. Performance could be quite poor if there are a large number of expression possibilities to evaluate, however this could be helped if the calling endpoint first evaluates the rest of the query and passes constraints within a VALUES clause.
    • A logical target for such a system would simply be a generic implementation of the full OWL 2 Direct Semantics Entailment Regime over the OWL API reasoner interface (Does this already exist?). But with the addition of owlet's convenient embedded OWL syntax expressions.
  • Embedding owlet within a triplestore
    • The current version of owlet could be reimagined, in much less reusable but possibly more efficient way, as an implementation of a custom function within existing triplestore software.
    • Bigdata supports custom Java functions, but it seems like implementation of a custom SERVICE would be the correct way to integrate.
    • An OWL API implementation of the OWL 2 Direct Semantics Entailment Regime (see above) could also be directly integrated into a Java-based triplestore (e.g. Bigdata).
Clone this wiki locally