> On Dec 18, 2017, at 8:17 AM, Andy Seaborne <[email protected]> wrote: > On 17/12/17 16:35, ajs6f wrote: >> >> 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.
I don't understand this very well-- to what architecture are you referring? How are we to use it? I'm all in favor of a unified exposure of a "maintain bnode identity" functionality, but to do that we have to find a way to expose it, period. Are you saying that Contexts are not the right choice because, as I pointed out elsewhere, they are an ARQ-specific construct? ajs6f > > 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! >>>> >>>
