Binding graph names for WITH and USING

Hi jena folks, I was surprised recently with a customer who was surprised that my jena connector did not properly bind graph names as variables after WITH. WITH ?g INSERT ... DELETE ... When I looked back at the SPARQL specs, it looks indeed true that variables are inadmissable after WITH

Re: Binding graph names for WITH and USING

USING is the like SELECT-FROM -- the WG decided a different name was better. It sets up the dataset to query in the WHERE clause. Again, there is no variable binding to use. It looks to me like you really want $resourceMetadataGraph to come from outside - a parametrized update. If so, the

Re: [3.0.1] listSuperClasses() does not traverse?

I ended up using JenaUtil.getAllSuperClasses() from SPINRDF: https://github.com/spinrdf/spinrdf/blob/a7fc9a1ca7badecb9a8d858f7a8a33bb106e629f/src/main/java/org/spinrdf/util/JenaUtil.java#L401 On Wed, Oct 25, 2017 at 1:22 PM, Martynas Jusevičius wrote: > Dave, > > I

Re: Binding graph names for WITH and USING

The error from Jena when I try to reproduce is fairly clear: @Test public void testGraphBinding() { MarkLogicDatasetGraph dsg = getMarkLogicDatasetGraph(); String updateQuery = "WITH ?g INSERT { \"1\" }"; BindingMap updateBindings = new

Re: Binding graph names for WITH and USING

What are they trying to achieve? The Update has a second error the parsers didn't get to. No WHERE clause - it's mandatory Did they mean: INSERT { GRAPH ?g { "1" } } WHERE { GRAPH ?g { } } GRAPH ?g { } returns all graph names. Where does

Re: Binding graph names for WITH and USING

good evening; > On 2017-10-25, at 18:48, Charles Greer wrote: > > Hi jena folks, I was surprised recently with a customer who was surprised > that my jena connector did not properly > > bind graph names as variables after WITH. > > > WITH ?g > > INSERT ... >

Re: Binding graph names for WITH and USING

Hi Charles, Indeed as the spec says: [41]Modify::= ( 'WITH' iri )? ( DeleteClause InsertClause? | InsertClause ) UsingClause* 'WHERE' GroupGraphPattern Where does the value for $g come from in the example? Andy On 25/10/17 17:48, Charles Greer wrote: Hi

Re: Run standalone Fuseki with no logs

http://jena.apache.org/documentation/fuseki2/fuseki-logging.html On 25/10/17 20:15, Laura Morales wrote: When I execute ./fuseki-server, all output is printed to screen. Fuseki prints all queries as "INFO". How can I disable all logs? Or maybe only display ERROR/WARN but no INFO?

Re: Run standalone Fuseki with no logs

Have you tried the locations for log configurations as described here: https://jena.apache.org/documentation/fuseki2/fuseki-logging.html#setting-logging ? ajs6f Laura Morales wrote on 10/25/17 9:15 PM: When I execute ./fuseki-server, all output is printed to screen. Fuseki prints all

Re: Fuseki+HDT graceful "File not found"

A service is a dataset (which could be on-disk or in-memory) along with some HTTP endpoints that support the protocols like SPARQL Query, SPARQL Update, Graph Store, etc. https://jena.apache.org/documentation/fuseki2/fuseki-data-services.html That page is super-rough and we really need to

Re: Binding graph names for WITH and USING

Hi Andy, I was trying to just recreate the scenario -- the original query did have a WHERE. I found it: prefix raf: with $resourceMetadataGraph delete {?urn raf:latest ?latest.} where {?urn raf:latest ?latest.} It was my attempt to present a workaround that ended up

Run standalone Fuseki with no logs

When I execute ./fuseki-server, all output is printed to screen. Fuseki prints all queries as "INFO". How can I disable all logs? Or maybe only display ERROR/WARN but no INFO?

Using Fuseki over HTTP

I want to rewrite Digraphs with Text[1] to use an external Datalog server, rather than the native Haskell module for graphs that it currently uses. Jena looks like the best open-source choice. I can run ./fuseki, visit http://localhost:3030, upload data and manually query it. I want to do those

Re: Does order of JOIN clauses affect performance

Are you using TDB? This page: https://jena.apache.org/documentation/tdb/optimizer.html gives some info about how TDB uses statistics to reorder queries. To my understanding (Andy can correct) graphs are not taken into account. TDB2 may be different... For other cases-- the transactional

Re: [3.0.1] listSuperClasses() does not traverse?

On 24/10/17 23:51, Martynas Jusevičius wrote: Hi, I thought I understood how OntClass.listSuperClasses() works, but maybe I don't. I have such a class structure in my ontology (superclass is at the top): 3. https://www.w3.org/ns/ldt/document-hierarchy/domain#Item 2.

Re: Does order of JOIN clauses affect performance

Hi Stefan, Within each GRAPH block there is a light amount of optimization (picking the first, most grounded tripe pattern; avoiding rdf:type) by default. There isn't anything across GRAPH blocks. TDB2 is the same as TDB1 in this regard (TDB2 is reworking the storage and transactions, not

Re: [3.0.1] listSuperClasses() does not traverse?

Thanks Dave. We are materializing inferences during ontology initialization to avoid using reasoner subsequently (as it impacts performance). So in that case I need to traverse the chain myself, correct? On Wed, Oct 25, 2017 at 9:33 AM, Dave Reynolds wrote: > On

Re: [3.0.1] listSuperClasses() does not traverse?

Hi Martynas, On 25/10/17 10:33, Martynas Jusevičius wrote: Thanks Dave. We are materializing inferences during ontology initialization to avoid using reasoner subsequently (as it impacts performance). Makes sense. So in that case I need to traverse the chain myself, correct? Not if

Re: [3.0.1] listSuperClasses() does not traverse?

On 25/10/17 11:10, George News wrote: On 2017-10-25 11:54, Dave Reynolds wrote: Hi Martynas, On 25/10/17 10:33, Martynas Jusevičius wrote: Thanks Dave. We are materializing inferences during ontology initialization to avoid using reasoner subsequently (as it impacts performance). Makes