Re: Signalling entailment in queries

On Tue, Jul 20, 2010 at 10:53 PM, Lee Feigenbaum <lee@thefigtrees.net> wrote:
> but that aside, LET has several
> implementations, including new implementations since the WG defined the
> original scope of our work. It also benefits from potentially having
> semantics that are already defined within the query language document. As
> far as I can tell, none of this is true for parametrized inference. As a WG
> Chair, I have been hesitant to expand our scope at all with LET, which is
> one reason I've let it drag on for so long; similarly, I'm extremely wary of
> taking on a new task such as signalling entailment, particularly given that
> this thread has illuminated many wide-open design decisions that would seem
> to need to be made without the ability to lean on existing implementations.

We have a product and two commercial solutions built on that product
that allow inference to be parameterized via endpoint; that is,
entailment regimes are associated with endpoints. This works fine,
it's an easy extension of a service discovery approach -- since the
entailment is just another RDF assertion about the endpoint URL -- and
it's sufficient for our needs.

Re: implementations, the product has 4 different client libraries
(Java, JS, Scala (coming), and another non-Java language), and they
allow SPARQL queries to parameterize entailment regimes by simply
routing queries to different endpoints.

Parameterizing entailment in the *query language* would be harder to
implement, harder to understand, and generally *yuck*. Or, put another
way, we wouldn't re-implement our product (hence, two solutions) or
any of the client libraries that we own to match that approach.

Cheers,
Kendall

Received on Wednesday, 21 July 2010 13:25:15 UTC