I was hoping we'd change it is because ATM it doesn't work properly and
is a bad design.
On 17/12/17 16:11, ajs6f wrote:
On Dec 17, 2017, at 11:08 AM, Andy Seaborne <[email protected]> wrote:
Why would it be dangerous?
As I wrote:
(in the sense in which you used the phrase "dubious in terms of spec
compliance")
It might confuse people into thinking that maintaining bnode labeling is a
normal part of using SPARQL, when it isn't-- it's something extra that Jena
provides.
If there's no reason this is an undocumented feature, I'm going to document it
at:
https://jena.apache.org/documentation/query/app_api.html
I prefer putting it, eventually, somewhere in advanced features.
Andy
ajs6f
On Dec 17, 2017, at 11:08 AM, Andy Seaborne <[email protected]> wrote:
Why would it be dangerous?
On 17/12/17 15:46, ajs6f wrote:
That is useful, and it's undocumented. Is that because it is dangerous (in the sense in
which you used the phrase "dubious in terms of spec compliance") or just
because we never have documented it?
ajs6f
On Dec 17, 2017, at 10:43 AM, Andy Seaborne <[email protected]> wrote:
ARQ.enableBlankNodeResultLabels()
On 17/12/17 15:39, ajs6f wrote:
Where? I found nothing documented.
ajs6f
On Dec 17, 2017, at 10:38 AM, Andy Seaborne <[email protected]> wrote:
On 17/12/17 15:19, ajs6f wrote:
Claude-- I'm looking at RDFConnection, but it's an interface. I think you mean
around L220 of JSONInput itself, right?
It looks like SyntaxLabels has some LabelToNode factory methods that might fit
the bill, like createNodeToLabelAsGiven(), but JSONInput doesn't offer any way
to select which method to use. At L195 it uses SyntaxLabels.createLabelToNode().
We could thread such a mapping choice all the way through the call stack, but
that seems a bit difficult to me. Maybe we could introduce a Context setting
for this purpose?
They already exist!
