- From: Holger Knublauch <holger@topquadrant.com>
- Date: Thu, 12 Feb 2015 10:57:37 +1000
- To: public-data-shapes-wg@w3.org
On 2/12/2015 10:34, Peter F. Patel-Schneider wrote: > Sure, but so what? LDOM is requiring a particular extension, and one > that may be difficult to implement efficiently. The LDOM procedural > extension looks to me to be of a completely different kind than the > what I take to be normal little filter functions in the SPARQL > documentation. Sure, but so what? Nobody stated that an LDOM engine would be trivial to implement. Just like a ShExC engine is not trivial to implement, nor an OWL inference engine. > Really? If SPIN can be implemented against an unmodified triple store > then that seems to be the way to go with LDOM too. Yes this is good to have as a general (fallback) solution. The price is performance. When you go through a stand-alone API such as Jena ARQ's engine to talk to a (remote) database then a lot of data has to be sent back and forth, to evaluate filters etc. If SPARQL databases have native LDOM support then they can do all this on their own, without extra traffic. >> Also note that AllegroGraph already supports recursively called SPIN >> functions that spawn off a new SPARQL query as part of another SPARQL >> query. > Does AllegroGraph also check to make sure that it is not in an infinite loop > when it is doing this? I don't know whether it does (my SPIN engine doesn't). But in the end it is the responsibility of the query author to make sure that their queries don't lead to infinite loops, just like in most programming languages where you get a stack overflow. The rest is a matter of exception handling. Holger
Received on Thursday, 12 February 2015 00:58:22 UTC