Re: consistent blank id values from RDFConnection

That is what PR#334 is about. #334 is ready for review. Andy On 24/12/17 10:31, Claude Warren wrote: Andy, Your solution works for part of my problem. Thx. Will it be in the 3.7.0 SNAPSHOT any time soon? The rest of my problem seems to require round-trip values. However, I will open

Re: consistent blank id values from RDFConnection

Andy, Your solution works for part of my problem. Thx. Will it be in the 3.7.0 SNAPSHOT any time soon? The rest of my problem seems to require round-trip values. However, I will open another discussion to explore if that is truly the case. Claude On Wed, Dec 20, 2017 at 9:58 AM, Claude

Re: consistent blank id values from RDFConnection

My issue was not in the Fuseki results but in the RDFConnection side. Basically it remaps the results. However, it looks like your change will work there as well. I'll give it a try. On Mon, Dec 18, 2017 at 5:27 PM, Andy Seaborne wrote: > Claude, > > This commit (on my Jena

Re: consistent blank id values from RDFConnection

Claude, This commit (on my Jena working copy): https://github.com/afs/jena/commit/5daab5fa2adf50140c35871eb84df2ec3966 fixes up JSON results for you ... if Fuseki and client are run with the right arguments. fuseki-basic --set arq:outputGraphBNodeLabels=true . then rsparql

Re: consistent blank id values from RDFConnection

eem conclusive, at least insofar as SPARQL >>> is concerned. >>> >>> >>> ________ >>> From: ajs6f <aj...@apache.org> >>> Sent: Sunday, December 17, 2017 10:19 AM >>> To: dev@jena.apache.org >>

Re: consistent blank id values from RDFConnection

nclusive, at least insofar as SPARQL is concerned. From: ajs6f <aj...@apache.org> Sent: Sunday, December 17, 2017 10:19 AM To: dev@jena.apache.org Subject: Re: consistent blank id values from RDFConnection That's not how I understand: http

Re: consistent blank id values from RDFConnection

Based on your comments, I need round tripping. I am assuming that the SPARQL server will return the same ID for the same blank nodes on multiple calls. I understand that not all servers will meet that requirement. In my case I am using SPARQL. I execute all queries via a RDFConnection to

Re: consistent blank id values from RDFConnection

Same here - this is the current use for RDF Delta where $job is running caches of graphs across a number of Tomcat servers. Blank nodes are handled by system id. There is a request for examples on https://afs.github.io/rdf-delta. Caching is one of several uses case for the system and one

Re: consistent blank id values from RDFConnection

Are you seeing { "type": "bnode" , "value": "b0" } for bytes on the wire? If so, and this would explain your UUID comment, then note that "b0" is not the internal blank node label. "b0" is result-document scoped. Both the serializer and deserializer do blank node scoping by default.

Re: consistent blank id values from RDFConnection

I am using the RDFConnectionFactory to create an RDFConnection to Fuseki. The issue arises when the Connection deserializes the result from Fuseki. Fuseki is returning the JSON format (I used no special settings for this, it just works this way out of the box) Using an RDFConnection to a local

Re: consistent blank id values from RDFConnection

My requirement centres around a caching graph. For my requirements I know that I am interested in subjects of triples so I can cache based on the subject. Long story short. When I query the RDFConnection for the second time I need the blank values to be the same as the first time so that I can

Re: consistent blank id values from RDFConnection

Okay, certainly I don't want to document something that is both hidden and faulty! :grin: I guess this is a general question (nothing to do with JSON in particular). How about a setting to enable any of the modes grouped in SyntaxLabels, for all parsing and output? Does that sound reasonable?

Re: consistent blank id values from RDFConnection

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 wrote: Why would it be dangerous? As I wrote: (in the sense in which you used the phrase "dubious in

Re: consistent blank id values from RDFConnection

t insofar as SPARQL > is concerned. > > > > From: ajs6f <aj...@apache.org> > Sent: Sunday, December 17, 2017 10:19 AM > To: dev@jena.apache.org > Subject: Re: consistent blank id values from RDFConnection > > That's not how I understand: > > https://www.w3.

Re: consistent blank id values from RDFConnection

You're right, that section does seem conclusive, at least insofar as SPARQL is concerned. From: ajs6f <aj...@apache.org> Sent: Sunday, December 17, 2017 10:19 AM To: dev@jena.apache.org Subject: Re: consistent blank id values from RDFConnection

Re: consistent blank id values from RDFConnection

-by-blank-nodes/44498034#44498034 From: ajs6f <aj...@apache.org> Sent: Sunday, December 17, 2017 10:11 AM To: dev@jena.apache.org Subject: Re: consistent blank id values from RDFConnection > On Dec 17, 2017, at 11:08 AM, Andy Seaborne <a...@apach

Re: consistent blank id values from RDFConnection

> On Dec 17, 2017, at 11:08 AM, Andy Seaborne 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

Re: consistent blank id values from RDFConnection

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

Re: consistent blank id values from RDFConnection

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 wrote: > >

Re: consistent blank id values from RDFConnection

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 wrote: On 17/12/17 15:19, ajs6f wrote: Claude-- I'm looking at RDFConnection, but it's an interface. I think you mean

Re: consistent blank id values from RDFConnection

Where? I found nothing documented. ajs6f > On Dec 17, 2017, at 10:38 AM, Andy Seaborne 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

Re: consistent blank id values from RDFConnection

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

Re: consistent blank id values from RDFConnection

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

consistent blank id values from RDFConnection

Greetings, I am looking at org.apache.jena.sparql.resultset.JSONInput and the way in which it parses blank nodes. I have a requirement for an application such that the same blank node returned on multiple queries returns the same blank node id. I have verified that Fuseki does this (given that