W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2010

Re: Signalling entailment in queries

From: Kendall Clark <kendall@clarkparsia.com>
Date: Wed, 21 Jul 2010 09:24:19 -0400
Message-ID: <AANLkTilw2sDGIYWG6-S7H6UbRcc9oEuyDyAiAWMc-_pV@mail.gmail.com>
To: Lee Feigenbaum <lee@thefigtrees.net>
Cc: Chimezie Ogbuji <ogbujic@ccf.org>, Sandro Hawke <sandro@w3.org>, SPARQL Working Group <public-rdf-dawg@w3.org>
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.

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:01 UTC