A JUnit test that illustrates the issue.

Please ignore the slashes in the query, I forgot to delete them after copying them out of the test case.

Sorry about this. I had two mistakes in my query,

WHERE
{
    ?subjectUri ?propertyUri ?objectUri .

should have been:

WHERE
{
    ?subjectUri ?predicateUri ?normalisedObjectUri .

Also:

 bind(iri(concat(\"http://oas.example.org/plantotology:\"

should have been:

 bind(iri(concat(\"http://oas.example.org/plantontology:\"

I fixed the spelling mistakes in the query and it executes properly in 2.5.1-SNAPSHOT

It is a little suspicious that the query engine hasn't been throwing exceptions relating to bindings in the construct template not being named.

You may want to investigate why an exception wasn't thrown when the construct template contained a variable that wasn't defined anywhere else in the query.

Thanks for the update Peter.

The reason bind currently fails silently is that it is implemented as an Extension, and this is designed to fail silently whenever a (type) error occurs. I will have a look at better behavior for this as clearly the current setup is not helpful for figuring out what's going wrong :)

Thanks for looking into this further. I am used to having parse or query execution exceptions when something goes wrong.

You may want to take into account the fact that the query generated 1 result, which included the bound variable, using the current 2.5.1-SNAPSHOT build, as that would (naively) seem to indicate that bind was working okay and there was a deeper issue with generating results sets.

Since the first triple pattern in the construct pattern was not optional in the where section, the entire results set shouldn't have been output without it being attached to something, unless I do not understand Sparql 1.1 properly.