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? 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! >> >
