- From: Kendall Clark <kendall@clarkparsia.com>
- Date: Wed, 21 Jul 2010 09:24:19 -0400
- 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. Cheers, Kendall
Received on Wednesday, 21 July 2010 13:25:15 UTC