You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Holger Knublauch <ho...@knublauch.com> on 2013/08/01 02:52:52 UTC

Replacement for UpdateProcessor.setInitialBindings?

I am upgrading our code base to the latest Jena snapshot, and noticed 
that UpdateProcessor.setInitialBindings is no longer around. What is the 
replacement for this functionality?

Thanks
Holger


Re: Replacement for UpdateProcessor.setInitialBindings?

Posted by Joshua TAYLOR <jo...@gmail.com>.
On Mon, Aug 5, 2013 at 8:39 AM, Holger Knublauch <ho...@knublauch.com> wrote:
>
> On Aug 5, 2013, at 6:28 PM, Andy Seaborne wrote:
>>> I cannot use ParameterizedSparqlString because it does not handle blank
>>> nodes correctly. The previous implementation using initial bindings
>>> supported this, because it didn't have to go through the string syntax.
>>> Now, when I pre-bind a variable to point to a blank node, I am getting
>>> strings like _:b0 which lose the identity of the blank node which is
>>> otherwise (fortunately) preserved throughout Jena.
>>>
>>> I am not sure if this is fixable in SPARQL syntax - please advise
>>> whether you want me to open a JIRA ticket - but as stated elsewhere I
>>> believe the initial bindings should be brought back into the update API.
>>>
>>> Thanks,
>>> Holger
>>>
>>
>> Use a URI like <_:LABEL> and you will be naming the blank node in the data, not making a query variable.
>
> I don't understand this. For example, I may have an update template
>
> INSERT {
>     GRAPH <target> {
>         ?node a:p ?o .
>     }
> }
> WHERE {
>     ?node a:p ?o .
> }
>
> where ?node is supplied as a pre-bound variable. The values may be URIs or blank nodes, and I want the target graph to use exactly the same blank node. (Slightly artificial but roughly one of our use cases).
>
> What would I need to do? ?node in the WHERE clause must be exactly the node from the QuerySolutionMap.

You might want to have a look at this thread from a few months back:

http://mail-archives.apache.org/mod_mbox/jena-users/201302.mbox/%3CCA+Q4JnkYoPMcTPOSKj7zs1OXg26qze7x5vLsozgi_M0g_5wdKg@mail.gmail.com%3E

I had to deal with a number of the same issues.

-- 
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/

Re: Replacement for UpdateProcessor.setInitialBindings?

Posted by Holger Knublauch <ho...@knublauch.com>.
On 8/6/2013 2:54, Rob Vesse wrote:
> pss.setIri("node", "_:blankNodeID");
This appears to work better - it now correctly matches the triples in 
the WHERE clause.

But now the INSERT is not correct. See test case, which creates the 
"inverse" of a triple involving a blank node. TemplateLib.subst seems to 
create the new blank node. If there are multiple iterations, it creates 
a new blank node in each iteration.

Thanks
Holger


Re: Replacement for UpdateProcessor.setInitialBindings?

Posted by Rob Vesse <rv...@yarcdata.com>.
pss.setIri("node", "_:blankNodeID");


As Andy states the IRI scheme _: is treated as referring to blank nodes in
the data rather than creating a temporary variable

Rob

On 8/5/13 5:39 AM, "Holger Knublauch" <ho...@knublauch.com> wrote:

>
>On Aug 5, 2013, at 6:28 PM, Andy Seaborne wrote:
>>> I cannot use ParameterizedSparqlString because it does not handle blank
>>> nodes correctly. The previous implementation using initial bindings
>>> supported this, because it didn't have to go through the string syntax.
>>> Now, when I pre-bind a variable to point to a blank node, I am getting
>>> strings like _:b0 which lose the identity of the blank node which is
>>> otherwise (fortunately) preserved throughout Jena.
>>> 
>>> I am not sure if this is fixable in SPARQL syntax - please advise
>>> whether you want me to open a JIRA ticket - but as stated elsewhere I
>>> believe the initial bindings should be brought back into the update
>>>API.
>>> 
>>> Thanks,
>>> Holger
>>> 
>> 
>> Use a URI like <_:LABEL> and you will be naming the blank node in the
>>data, not making a query variable.
>
>I don't understand this. For example, I may have an update template
>
>INSERT {
>    GRAPH <target> {
>        ?node a:p ?o .
>    }
>}
>WHERE {
>    ?node a:p ?o .
>}
>
>where ?node is supplied as a pre-bound variable. The values may be URIs
>or blank nodes, and I want the target graph to use exactly the same blank
>node. (Slightly artificial but roughly one of our use cases).
>
>What would I need to do? ?node in the WHERE clause must be exactly the
>node from the QuerySolutionMap.
>
>Thanks,
>Holger
>


Re: Replacement for UpdateProcessor.setInitialBindings?

Posted by Holger Knublauch <ho...@knublauch.com>.
On Aug 5, 2013, at 6:28 PM, Andy Seaborne wrote:
>> I cannot use ParameterizedSparqlString because it does not handle blank
>> nodes correctly. The previous implementation using initial bindings
>> supported this, because it didn't have to go through the string syntax.
>> Now, when I pre-bind a variable to point to a blank node, I am getting
>> strings like _:b0 which lose the identity of the blank node which is
>> otherwise (fortunately) preserved throughout Jena.
>> 
>> I am not sure if this is fixable in SPARQL syntax - please advise
>> whether you want me to open a JIRA ticket - but as stated elsewhere I
>> believe the initial bindings should be brought back into the update API.
>> 
>> Thanks,
>> Holger
>> 
> 
> Use a URI like <_:LABEL> and you will be naming the blank node in the data, not making a query variable.

I don't understand this. For example, I may have an update template

INSERT {
    GRAPH <target> {
        ?node a:p ?o .
    }
}
WHERE {
    ?node a:p ?o .
}

where ?node is supplied as a pre-bound variable. The values may be URIs or blank nodes, and I want the target graph to use exactly the same blank node. (Slightly artificial but roughly one of our use cases).

What would I need to do? ?node in the WHERE clause must be exactly the node from the QuerySolutionMap.

Thanks,
Holger


Re: Replacement for UpdateProcessor.setInitialBindings?

Posted by Andy Seaborne <an...@apache.org>.
On 05/08/13 04:12, Holger Knublauch wrote:
> On 8/2/2013 0:12, Andy Seaborne wrote:
>> On 01/08/13 01:52, Holger Knublauch wrote:
>>> I am upgrading our code base to the latest Jena snapshot, and noticed
>>> that UpdateProcessor.setInitialBindings is no longer around. What is the
>>> replacement for this functionality?
>>>
>>> Thanks
>>> Holger
>>>
>>
>> Holger,
>>
>> https://jena.apache.org/documentation/query/parameterized-sparql-strings.html
>>
>>
>> http://jena.apache.org/documentation/javadoc/arq/com/hp/hpl/jena/query/ParameterizedSparqlString.html
>>
>
> I cannot use ParameterizedSparqlString because it does not handle blank
> nodes correctly. The previous implementation using initial bindings
> supported this, because it didn't have to go through the string syntax.
> Now, when I pre-bind a variable to point to a blank node, I am getting
> strings like _:b0 which lose the identity of the blank node which is
> otherwise (fortunately) preserved throughout Jena.
>
> I am not sure if this is fixable in SPARQL syntax - please advise
> whether you want me to open a JIRA ticket - but as stated elsewhere I
> believe the initial bindings should be brought back into the update API.
>
> Thanks,
> Holger
>

Use a URI like <_:LABEL> and you will be naming the blank node in the 
data, not making a query variable.

	Andy




Re: Replacement for UpdateProcessor.setInitialBindings?

Posted by Holger Knublauch <ho...@knublauch.com>.
On 8/2/2013 0:12, Andy Seaborne wrote:
> On 01/08/13 01:52, Holger Knublauch wrote:
>> I am upgrading our code base to the latest Jena snapshot, and noticed
>> that UpdateProcessor.setInitialBindings is no longer around. What is the
>> replacement for this functionality?
>>
>> Thanks
>> Holger
>>
>
> Holger,
>
> https://jena.apache.org/documentation/query/parameterized-sparql-strings.html 
>
>
> http://jena.apache.org/documentation/javadoc/arq/com/hp/hpl/jena/query/ParameterizedSparqlString.html 
>

I cannot use ParameterizedSparqlString because it does not handle blank 
nodes correctly. The previous implementation using initial bindings 
supported this, because it didn't have to go through the string syntax. 
Now, when I pre-bind a variable to point to a blank node, I am getting 
strings like _:b0 which lose the identity of the blank node which is 
otherwise (fortunately) preserved throughout Jena.

I am not sure if this is fixable in SPARQL syntax - please advise 
whether you want me to open a JIRA ticket - but as stated elsewhere I 
believe the initial bindings should be brought back into the update API.

Thanks,
Holger


Re: Replacement for UpdateProcessor.setInitialBindings?

Posted by Joshua TAYLOR <jo...@gmail.com>.
On Thu, Aug 1, 2013 at 10:12 AM, Andy Seaborne <an...@apache.org> wrote:
> On 01/08/13 01:52, Holger Knublauch wrote:
>>
>> I am upgrading our code base to the latest Jena snapshot, and noticed
>> that UpdateProcessor.setInitialBindings is no longer around. What is the
>> replacement for this functionality?
>>
>> Thanks
>> Holger
>>
>
> Holger,
>
> https://jena.apache.org/documentation/query/parameterized-sparql-strings.html
> http://jena.apache.org/documentation/javadoc/arq/com/hp/hpl/jena/query/ParameterizedSparqlString.html

It's also possible to simulate the initial bindings by using a VALUES
block on the query.  This also has the advantage that it can be used
for binding a number of solutions at once.  Here's an example:

import java.io.ByteArrayInputStream;
import java.util.ArrayList;
import java.util.List;

import com.hp.hpl.jena.query.Query;
import com.hp.hpl.jena.query.QueryExecutionFactory;
import com.hp.hpl.jena.query.QueryFactory;
import com.hp.hpl.jena.query.QuerySolution;
import com.hp.hpl.jena.query.ResultSet;
import com.hp.hpl.jena.query.ResultSetFormatter;
import com.hp.hpl.jena.rdf.model.Model;
import com.hp.hpl.jena.rdf.model.ModelFactory;
import com.hp.hpl.jena.rdf.model.RDFNode;
import com.hp.hpl.jena.sparql.core.Var;
import com.hp.hpl.jena.sparql.engine.binding.Binding;
import com.hp.hpl.jena.sparql.engine.binding.BindingFactory;


public class ValuesInsteadOfInitialBindings {
	@SuppressWarnings("serial")
	public static void main(String[] args) {
		final String ttlContent = "" +
				"@prefix : <http://example.org/> .\n" +
				"\n" +
				":a :p :x ;\n" +
				"   :q :aa .\n" +
				":b :p :x ;\n" +
				"   :q :bb .\n" +
				":c :p :y.\n" +
				"";
		
		// Setup a model with the data above
		final Model model = ModelFactory.createDefaultModel();
		model.read( new ByteArrayInputStream( ttlContent.getBytes() ), null, "TTL" );
		
		final String thingsThatPX = ""+
				"prefix : <http://example.org/>\n" +
				"select * where {\n" +
				"  ?thing :p :x .\n" +
				"}\n" +
				"";
		
		// Get a result set that binds ?thing to each value that :x
		// as a value for :p
		final ResultSet results = QueryExecutionFactory.create(
thingsThatPX, model ).execSelect();
		
		// A query that retrieves the ?qValue of each ?thing. ?thing here
has no binding
		// and would match *everything* that has a value for :q.
		final String qOfThings = "" +
				"prefix : <http://example.org/>\n" +
				"select * where {\n" +
				"  ?thing :q ?qValue .\n" +
				"}\n" +
				"";
		
		// Create the query and show it, before setting up
		// any VALUES.
		final Query query = QueryFactory.create( qOfThings );
		System.out.println( query );
		
		// Create variables and bindings for the VALUES block
		final List<Var> variables = new ArrayList<Var>() {{
			for ( final String varName : results.getResultVars() ) {
				add( Var.alloc( varName ));
			}
		}};
		final List<Binding> bindings = new ArrayList<Binding>() {{
			while ( results.hasNext() ) {
				final QuerySolution solution = results.next();
				for ( final Var var : variables ) {
					add( BindingFactory.binding( var, solution.get( var.getName()
).asNode() ));
				}
			}
		}};

		// Set the VALUES block and show the query again.
		query.setValuesDataBlock( variables, bindings );
		System.out.println( query );
		
		// Show the final results
		ResultSetFormatter.out( QueryExecutionFactory.create( query, model
).execSelect() );
	}
}



-- 
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/

Re: Replacement for UpdateProcessor.setInitialBindings?

Posted by Andy Seaborne <an...@apache.org>.
On 01/08/13 01:52, Holger Knublauch wrote:
> I am upgrading our code base to the latest Jena snapshot, and noticed
> that UpdateProcessor.setInitialBindings is no longer around. What is the
> replacement for this functionality?
>
> Thanks
> Holger
>

Holger,

https://jena.apache.org/documentation/query/parameterized-sparql-strings.html

http://jena.apache.org/documentation/javadoc/arq/com/hp/hpl/jena/query/ParameterizedSparqlString.html

	Andy