On 17/12/17 16:35, ajs6f wrote:
It's certainly a long-running discussion. I.e., there are sound reasons that
bnodes are treated as they are in the recommendations, and as Andy remarked
(and Claude and Andy prove with their use cases), there are sound reasons that
one might like to enlarge the scope for identity just a bit, now and then.
I think offering configurability is a good middle ground. Claude-- does that
ARQ option meet your needs?
Andy-- do you think pulling all the related config into Context Symbols would be a good way to "pull together" the API?, as you suggest?
It is the end-to-end coordination of a number of steps in different
places. Graphs haven't even been mentioned so far. I think exposing the
machinery piecemeal is bad (= unhelpful; encourages misuse; does not
work in the system as a whole where other things are going on). We have
the right architecture, let's use it.
Andy
Context values are a little more "fine-grained" than static settings, and can
vary within an app more easily.
ajs6f
On Dec 17, 2017, at 11:29 AM, Adam Jacobs <[email protected]> wrote:
You're right, that section does seem conclusive, at least insofar as SPARQL is
concerned.
________________________________________
From: ajs6f <[email protected]>
Sent: Sunday, December 17, 2017 10:19 AM
To: [email protected]
Subject: Re: consistent blank id values from RDFConnection
That's not how I understand:
https://www.w3.org/TR/sparql11-query/#BlankNodesInResults
"Blank node labels are scoped to a result set (see "SPARQL Query Results XML Format" and
"SPARQL 1.1 Query Results JSON Format") or, for the CONSTRUCT query form, the result graph."
Multiple calls to a single graph => multiple queries => multiple result sets (or
result graphs) => multiple scopes.
ajs6f
On Dec 17, 2017, at 11:15 AM, Adam Jacobs <[email protected]> wrote:
My understanding is there's nothing wrong with maintaining labels among
multiple calls to a single graph.
The danger would be the risk of maintaining labels among calls to multiple
graphs.
At least, that's what I get out of this SO answer:
https://stackoverflow.com/questions/44477876/grouping-by-blank-nodes/44498034#44498034
________________________________________
From: ajs6f <[email protected]>
Sent: Sunday, December 17, 2017 10:11 AM
To: [email protected]
Subject: Re: consistent blank id values from RDFConnection
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
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!
