rvesse commented on issue #3267: URL: https://github.com/apache/jena/issues/3267#issuecomment-2995619008
> What is the reason why SELECT would still work as before while CONSTRUCT/INSERT produce new blank nodes? As I already pointed to the SPARQL specification defines the semantics of blank nodes in templates, used in `CONSTRUCT` and `INSERT`, specifically such that blank nodes are treated as placeholders used to generate new blank nodes for each solution. Whereas for a `SELECT` it depends where you inserted the blank node. In your example you put it in the project expressions which happens to work (though honestly I'm surprised it does, that may actually be a bug in substitution) if you had put it in the BGP then it would most likely have been treated as a variable and probably not given you the result you wanted/expected. > Also, are there technical reasons why the old behaviour couldn't be restored for substitution too? Yes, as @afs already said: >> Initial binding in local execution is a limitation affecting all query execution and hinders development of the query execution. It's a feature that only works for local execution and mostly does so by subverting SPARQL semantics hence why you are able to get some of the behaviours you consider "expected". Legacy features in the project are maintenance overhead, the project is driven entirely by volunteer effort and has no paid contributors. While some of us have from time to time been afforded some small fraction of our $dayjob to make contributions it has been an incredibly small fraction of our time, and usually only to address specific issues pertinent to our employers. Volunteers cannot maintain every feature forever, especially when a feature hinders evolution of the project that volunteers actually want/have the time and energy to spend on it. Whereas the new approach Substitution aims to be standard compliant, and works across all kinds of query execution, including remote. > We may not be able to upgrade to 6.0 and may instead have to maintain our own fork of Jena. That seems somewhat of an extreme reaction Many of Jena's APIs, including query execution, are inherently designed to be extensible. If you really cannot live without initial bindings then you would likely be better off simply providing a custom query engine for your use case that provides that feature, lifting the deprecated code from Jena as needed. Custom query engines are pretty lightweight to maintain and keep up to date with Jena releases. I maintained one for many years in a previous job where the SPARQL engine needed specific algebra optimisations applying, custom algebra for some operators etc. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
