Re: potential new API Was: Immutability

I just want to mention that it was not my intent to derail progress on Jena-1391 (https://issues.apache.org/jira/browse/JENA-1391) by raising the issue of immutability, particularly if immutability would be implemented via a new API. I don't think it should be considered a blocker to that

Re: Jena-1427 - nextOptional()

Note that the original request in Jena-1427 was for a nextOrElse() method accepting an instance of Supplier. The implementation of nextOptional(), released in version 3.6, solves my use case just as well. The only reason I had not requested nextOptional() directly is that ExtendedIterator was

[jira] [Created] (JENA-1451) DatasetFactory.createGeneral() never contains default graph

Adam Jacobs created JENA-1451: - Summary: DatasetFactory.createGeneral() never contains default graph Key: JENA-1451 URL: https://issues.apache.org/jira/browse/JENA-1451 Project: Apache Jena

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.

[jira] [Updated] (JENA-1418) Upgrade minor dependencies

[ https://issues.apache.org/jira/browse/JENA-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-1418: Fix Version/s: (was: Jena 3.6.0) Jena 3.7.0 > Upgrade minor dependencies >

[jira] [Commented] (JENA-1450) Add fn:error

[ https://issues.apache.org/jira/browse/JENA-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16294307#comment-16294307 ] ASF GitHub Bot commented on JENA-1450: -- Github user ajs6f commented on a diff in the pull request:

[GitHub] jena pull request #331: JENA-1450: fn:error

Github user ajs6f commented on a diff in the pull request: https://github.com/apache/jena/pull/331#discussion_r157378417 --- Diff: jena-arq/src/main/java/org/apache/jena/sparql/function/library/FN_Error.java --- @@ -0,0 +1,66 @@ +/* + * Licensed to the Apache Software

[GitHub] jena pull request #331: JENA-1450: Fn error

GitHub user afs opened a pull request: https://github.com/apache/jena/pull/331 JENA-1450: Fn error You can merge this pull request into a Git repository by running: $ git pull https://github.com/afs/jena fn_error Alternatively you can review and apply these changes as the

[jira] [Commented] (JENA-1450) Add fn:error

[ https://issues.apache.org/jira/browse/JENA-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16294305#comment-16294305 ] ASF GitHub Bot commented on JENA-1450: -- GitHub user afs opened a pull request:

[jira] [Created] (JENA-1450) Add fn:error

Andy Seaborne created JENA-1450: --- Summary: Add fn:error Key: JENA-1450 URL: https://issues.apache.org/jira/browse/JENA-1450 Project: Apache Jena Issue Type: Improvement Affects Versions:

[GitHub] jena issue #329: Give more time to ElasticSearch to startup

Github user ajs6f commented on the issue: https://github.com/apache/jena/pull/329 Ah, I think I figured it out-- for future reference, this seems to happen when you merge a branch into `master` and push it, but the branch on Github isn't up to date with the local repo. Okay, I should

[GitHub] jena pull request #329: Give more time to ElasticSearch to startup

Github user ajs6f closed the pull request at: https://github.com/apache/jena/pull/329 ---

[GitHub] jena issue #329: Give more time to ElasticSearch to startup

Github user ajs6f commented on the issue: https://github.com/apache/jena/pull/329 Dang it! This is the second time this has happened. I've been merging my PR branches into `master` and then pushing them. It normally works fine... I need to figure out what's nutty on my end. In the

[jira] [Resolved] (JENA-1435) Provide extensibility of Fuseki with new services.

[ https://issues.apache.org/jira/browse/JENA-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne resolved JENA-1435. - Resolution: Done Fix Version/s: Jena 3.7.0 > Provide extensibility of Fuseki with new

[GitHub] jena issue #299: Turtle Star

Github user afs commented on the issue: https://github.com/apache/jena/pull/299 @mschroeder-github, @hartig Apache Jena 3.6.0 is out and has `Node_Triple` for you. Feedback etc welcome - this is an experimental feature and can be revised. Note - this does not mean parsers

[jira] [Commented] (JENA-1435) Provide extensibility of Fuseki with new services.

[ https://issues.apache.org/jira/browse/JENA-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16294285#comment-16294285 ] ASF subversion and git services commented on JENA-1435: --- Commit

[jira] [Commented] (JENA-1435) Provide extensibility of Fuseki with new services.

[ https://issues.apache.org/jira/browse/JENA-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16294280#comment-16294280 ] ASF subversion and git services commented on JENA-1435: --- Commit

[jira] [Commented] (JENA-1435) Provide extensibility of Fuseki with new services.

[ https://issues.apache.org/jira/browse/JENA-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16294284#comment-16294284 ] ASF subversion and git services commented on JENA-1435: --- Commit

[jira] [Commented] (JENA-1435) Provide extensibility of Fuseki with new services.

[ https://issues.apache.org/jira/browse/JENA-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16294282#comment-16294282 ] ASF subversion and git services commented on JENA-1435: --- Commit

[jira] [Commented] (JENA-1435) Provide extensibility of Fuseki with new services.

[ https://issues.apache.org/jira/browse/JENA-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16294286#comment-16294286 ] ASF GitHub Bot commented on JENA-1435: -- Github user asfgit closed the pull request at:

[jira] [Commented] (JENA-1435) Provide extensibility of Fuseki with new services.

[ https://issues.apache.org/jira/browse/JENA-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16294283#comment-16294283 ] ASF subversion and git services commented on JENA-1435: --- Commit

[jira] [Commented] (JENA-1435) Provide extensibility of Fuseki with new services.

[ https://issues.apache.org/jira/browse/JENA-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16294281#comment-16294281 ] ASF subversion and git services commented on JENA-1435: --- Commit

[GitHub] jena pull request #316: JENA-1435: Add service extensibilty to Fuseki2.

Github user asfgit closed the pull request at: https://github.com/apache/jena/pull/316 ---

Re: Jena-1427 - nextOptional()

> On Dec 17, 2017, at 2:18 PM, Claude Warren wrote: > It seems that much of the rest of the discussion is covered by adding a > method to convert the iterator to a stream (probably just a call to an > existing Java method. Just to this point alone-- this is something that

Re: Jena-1427 - nextOptional()

>From the original request it seems the requirements were: 1. return a default value if the iterator is empty. 2. throw a custom exception if the iterator is empty. Perhaps we should add a next( T default ) method that will return the default if hasNext() returns false. This seem better than

[GitHub] jena issue #329: Give more time to ElasticSearch to startup

Github user afs commented on the issue: https://github.com/apache/jena/pull/329 There is a different commit ee9c98b108942f258fd9a6b2e02cc6104a648368 on the Jena ASF git repository. This can be closed? For next time, it would be good to use the same commit:

[RESULT] [VOTE] Apache Jena 3.6.0 RC1

The VOTE passes with 4 binding +1 : Rob, Bruno, ajs6f and Andy On to the next stage of pushing bytes and website out. Andy On 13/12/17 23:27, Andy Seaborne wrote: Hi, Here is a vote on a release of Jena 3.6.0. This is the first proposed candidate for a 3.5.0 release. Note - the

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: Jena-1427 - nextOptional()

We seem to have drifted a bit here - the original use case wasn't about streaming as I read it. list* get used to write zero/one tests and one/many tests dealing with properties etc. And, of course, we want to avoid the anti-pattern of Optional/if-empty. Claude - thoughts on the use case? How

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: DatasetFactory.createGeneral()

Hi Adam, Thanks for details. On 17/12/17 16:57, Adam Jacobs wrote: I've noticed a couple of differences between DatasetFactory.create() and DatasetFactory.createGeneral(). My understanding is that the former is intended to create deep copies of its graphs whereas the latter maintains shallow

DatasetFactory.createGeneral()

I've noticed a couple of differences between DatasetFactory.create() and DatasetFactory.createGeneral(). My understanding is that the former is intended to create deep copies of its graphs whereas the latter maintains shallow links. The DatasetFactory has quite a few creational methods, and

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

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,

Re: consistent blank id values from RDFConnection

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

Re: Jira and Gitbox integration?

Any news? Even after reading around, I still don't know how JIRA fits in (if at all). It might only send emails c.f commits@. A github only flow is fine by me. Loosing JIRA will be a bump but it is a question of balance - more GH input vs undoing what we have talked about for some time

Re: consistent blank id values from RDFConnection

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:

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

Re: [VOTE] Apache Jena 3.6.0 RC1

X ] +1 Approve the release Build ran fine (`mvn clean install`) , source is present, I spot-checked the sigs and checksums and everything looks good. Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T15:39:06-04:00) Java version: 1.8.0_65, vendor: Oracle Corporation