You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@marmotta.apache.org by Paul Danckaert <pa...@tacticaledge.us> on 2014/09/30 19:46:19 UTC
LDClient Implementation Troubles
Greetings!
So I have implemented a test client that retrieves data from remote systems, using the example providers as a skeleton for putting this together. When I run the tests, I do actually see the RDF data generated and returned as the tests complete.
My challenge is, I haven't been able to run a SPARQL query directly through the web interface to perform the same action. Using the same query that I used in my test framework, I get a NO response. Basically just running:
ASK {
<http://test.org/local/MyTown> ?s ?o .
}
So when this query runs in my junit tests, I see the RDF generated on the console properly, and of course the debugging from it's execution. When I tried to install this into the server, I put the generated jar file into the WEB-INF/lib directory and restarted.
When the server starts I do see both the endpoint and provider in the lists in the log files, but running the same query through the SPARQL interface simply returns "No".
Any thoughts or ideas on how to properly register or call this endpoint/provider?
thanks,
paul
Re: LDClient Implementation Troubles
Posted by Sergio Fernández <wi...@apache.org>.
Hi Paul,
On 30/09/14 19:46, Paul Danckaert wrote:
> When the server starts I do see both the endpoint and provider in the lists in the log files, but running the same query through the SPARQL interface simply returns "No".
Unfortunately the default SPARQL evaluation does not trigger LDCache.
If you want that feature while SPARQLing, you would need to switch the
"sparql.strategy" configuration option from "native" to "sesame".
The background is that in KiWi the native strategy uses a "short path"
for translating SPARQL queries directly into SQL on the underlying
database. The disadvantage is that certain repository layers (like the
Linked Data Caching) will not be triggered. The main advantage is the
performance, because the SPARQL queries do not run over the expensive
in-memory API and are therefore much faster.
Then it's up to you, performance vs. having transparently cache on
SPARQL querying.
> Any thoughts or ideas on how to properly register or call this endpoint/provider?
Depending on the needs in your queries, maybe you can switch to LDPath,
which does trigger LDCache on path evaluation.
Direct requests to the /resource webservice would also trigger it:
http://host/marmotta/resource?uri=http%3A%2F%2Ftest.org%2Flocal%2FMyTown
Hope that helps to understand the issue.
Cheers,
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: sergio.fernandez@redlink.co
w: http://redlink.co