[jira] [Commented] (JENA-2073) RAT check missing license in Fuseki2

[Bruno P. Kinoshita (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17305603#comment-17305603
 ] 

Bruno P. Kinoshita commented on JENA-2073:
--

Hi [~MrPekar]

Could be that this file was created after you imported this project in IntelliJ 
or similar IDE? I can't see this jena-fuseki-geosparql.iml file here: 
[https://github.com/apache/jena/tree/main/jena-fuseki2/jena-fuseki-geosparql]

In case that file was created locally, you have two options I think:
 # You can add an entry to the project's .gitignore for *.iml, however, that 
would also appear in your git status output, which can be annoying if you want 
to submit a PR
 # Edit your ~/.gitignore file and add an entry for *.iml. That file is your 
own user gitignore, and is applied to every git project

Bruno

> RAT check missing license in Fuseki2
> 
>
> Key: JENA-2073
> URL: https://issues.apache.org/jira/browse/JENA-2073
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.17.0
>Reporter: Martin Pekár
>Priority: Blocker
>  Labels: build
> Fix For: Jena 3.17.0
>
>
> I cannot build the project because of RAT check unapproved license in file 
> jena-fuseki2/jena-fuseki-geosparql/jena-fuseki-geosparql.iml



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (JENA-2096) Add CLI&Fuseki parameters to delete old DB after compaction has completed successfully

[Bruno P. Kinoshita (Jira)]

Bruno P. Kinoshita created JENA-2096:


 Summary: Add CLI&Fuseki parameters to delete old DB after 
compaction has completed successfully
 Key: JENA-2096
 URL: https://issues.apache.org/jira/browse/JENA-2096
 Project: Apache Jena
  Issue Type: Improvement
  Components: cmd, Fuseki
Affects Versions: Jena 4.0.0
Reporter: Bruno P. Kinoshita


Placeholder for https://github.com/apache/jena/pull/988



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (JENA-1911) Update Fuseki 2 UI JS code

[Bruno P. Kinoshita (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita closed JENA-1911.

Resolution: Won't Fix

> Update Fuseki 2 UI JS code
> --
>
> Key: JENA-1911
> URL: https://issues.apache.org/jira/browse/JENA-1911
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki
>Affects Versions: Jena 3.15.0
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Attachments: image-2020-06-05-12-09-57-685.png, 
> image-2020-06-05-12-11-01-945.png, image-2020-06-05-12-13-40-428.png, 
> image-2020-06-05-12-15-19-199.png
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The existing Jena Fuseki user interface uses Backbone.js, with extra 
> libraries such as JQuery, Marionette.js. The JavaScript code pre-dates ES6, 
> which is largely supported now.
> This issue is a placeholder for discussion & work around updating the UI. 
> Using ES6 in the code would be a great improvement.
> But I also suggesting adopting a different framework. The most famous 
> framework for JS UI is probably React, followed by Angular & Vue. I am using 
> Vue.js at $work, so I am biased.
> The reason we chose Vue.js at work is that the development team is using 
> mainly Python, with background in Perl, C, and Shell. So out of the three, 
> Vue.js was the simplest, as it didn't require TypeScript, special syntax, and 
> the tools required to build an app with Vue are also quite simple.
> One downside of this approach is the build of Apache Jena, which would 
> require Node.js and a build tool like Yarn or NPM. But it also brings 
> benefits such as:
>  * We can write unit tests for the UI
>  * We can write integration (e2e, end to end) tests with Cypress or 
> Nightwatch (similar to Selenium, but simpler to run and maintain)
>  * It will be easier to keep the code up to date, as tools like GitHub 
> security bot are able to inspect package.json and look for outdated or 
> libraries with CVE's
>  * It will be easier to incorporate other libraries in the code, so that we 
> can easily switch the JS code for the editor (for example), or add a new 
> library to handle SPARQL, etc
>  * It is now easier to find developers that know Vue, React, Angular, than 
> Backbone (though that was the first framework I learned, and I really like 
> it), so maybe we would get more contributors to help with Fuseki UI
> So features we would have after this issue:
>  * Application built with ES6 JavaScript code
>  * Using Vue.js as framework for the UI
>  * Adding accessibility support (WCAG 2.0, mybe covering section 508 
> though I'm not quite familiar as that's more for US)
>  * Update all the JS libraries
>  * Add documentation to the code with JSDoc (the current code lacks 
> documentation)
>  * Add tests, both unit and end-to-end (also not present in current code)
>  * Maintain the look and feel with Bootstrap, and limit what is changed (i.e. 
> users are already familiar with Fuseki, and know they can upload data, run 
> queries, etc, so we should make sure that they are able to find it)
>  * Theming, with a default light-mode, a dark-mode, and (possibly?) 
> color-blind or other custom themes
>  * Work on mobile/responsive viewports
>  * Local browser settings; this is something cheap, that doesn't require 
> changing to the backend, and would allow us to persist user settings such as:
>  ** Previous executed Queries
>  ** Extra query prefixes
>  ** Number of datasets displayed per page in the main page
>  ** How long the server status widget queries the server (i.e. should we ping 
> it every 1 hour? every 30 seconds?)
>  ** The theme of the user (dark, light, color-blind-protanopia, 
> high-contrast, etc) leveraging bootstrap-vue
>  ** User language



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Reopened] (JENA-1911) Update Fuseki 2 UI JS code

[Bruno P. Kinoshita (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita reopened JENA-1911:
--

> Update Fuseki 2 UI JS code
> --
>
> Key: JENA-1911
> URL: https://issues.apache.org/jira/browse/JENA-1911
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki
>Affects Versions: Jena 3.15.0
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Attachments: image-2020-06-05-12-09-57-685.png, 
> image-2020-06-05-12-11-01-945.png, image-2020-06-05-12-13-40-428.png, 
> image-2020-06-05-12-15-19-199.png
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The existing Jena Fuseki user interface uses Backbone.js, with extra 
> libraries such as JQuery, Marionette.js. The JavaScript code pre-dates ES6, 
> which is largely supported now.
> This issue is a placeholder for discussion & work around updating the UI. 
> Using ES6 in the code would be a great improvement.
> But I also suggesting adopting a different framework. The most famous 
> framework for JS UI is probably React, followed by Angular & Vue. I am using 
> Vue.js at $work, so I am biased.
> The reason we chose Vue.js at work is that the development team is using 
> mainly Python, with background in Perl, C, and Shell. So out of the three, 
> Vue.js was the simplest, as it didn't require TypeScript, special syntax, and 
> the tools required to build an app with Vue are also quite simple.
> One downside of this approach is the build of Apache Jena, which would 
> require Node.js and a build tool like Yarn or NPM. But it also brings 
> benefits such as:
>  * We can write unit tests for the UI
>  * We can write integration (e2e, end to end) tests with Cypress or 
> Nightwatch (similar to Selenium, but simpler to run and maintain)
>  * It will be easier to keep the code up to date, as tools like GitHub 
> security bot are able to inspect package.json and look for outdated or 
> libraries with CVE's
>  * It will be easier to incorporate other libraries in the code, so that we 
> can easily switch the JS code for the editor (for example), or add a new 
> library to handle SPARQL, etc
>  * It is now easier to find developers that know Vue, React, Angular, than 
> Backbone (though that was the first framework I learned, and I really like 
> it), so maybe we would get more contributors to help with Fuseki UI
> So features we would have after this issue:
>  * Application built with ES6 JavaScript code
>  * Using Vue.js as framework for the UI
>  * Adding accessibility support (WCAG 2.0, mybe covering section 508 
> though I'm not quite familiar as that's more for US)
>  * Update all the JS libraries
>  * Add documentation to the code with JSDoc (the current code lacks 
> documentation)
>  * Add tests, both unit and end-to-end (also not present in current code)
>  * Maintain the look and feel with Bootstrap, and limit what is changed (i.e. 
> users are already familiar with Fuseki, and know they can upload data, run 
> queries, etc, so we should make sure that they are able to find it)
>  * Theming, with a default light-mode, a dark-mode, and (possibly?) 
> color-blind or other custom themes
>  * Work on mobile/responsive viewports
>  * Local browser settings; this is something cheap, that doesn't require 
> changing to the backend, and would allow us to persist user settings such as:
>  ** Previous executed Queries
>  ** Extra query prefixes
>  ** Number of datasets displayed per page in the main page
>  ** How long the server status widget queries the server (i.e. should we ping 
> it every 1 hour? every 30 seconds?)
>  ** The theme of the user (dark, light, color-blind-protanopia, 
> high-contrast, etc) leveraging bootstrap-vue
>  ** User language



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (JENA-1911) Update Fuseki 2 UI JS code

[Bruno P. Kinoshita (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita resolved JENA-1911.
--
Resolution: Fixed

> Update Fuseki 2 UI JS code
> --
>
> Key: JENA-1911
> URL: https://issues.apache.org/jira/browse/JENA-1911
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki
>Affects Versions: Jena 4.3.2
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: Jena 4.4.0
>
> Attachments: image-2020-06-05-12-09-57-685.png, 
> image-2020-06-05-12-11-01-945.png, image-2020-06-05-12-13-40-428.png, 
> image-2020-06-05-12-15-19-199.png
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The existing Jena Fuseki user interface uses Backbone.js, with extra 
> libraries such as JQuery, Marionette.js. The JavaScript code pre-dates ES6, 
> which is largely supported now.
> This issue is a placeholder for discussion & work around updating the UI. 
> Using ES6 in the code would be a great improvement.
> But I also suggesting adopting a different framework. The most famous 
> framework for JS UI is probably React, followed by Angular & Vue. I am using 
> Vue.js at $work, so I am biased.
> The reason we chose Vue.js at work is that the development team is using 
> mainly Python, with background in Perl, C, and Shell. So out of the three, 
> Vue.js was the simplest, as it didn't require TypeScript, special syntax, and 
> the tools required to build an app with Vue are also quite simple.
> One downside of this approach is the build of Apache Jena, which would 
> require Node.js and a build tool like Yarn or NPM. But it also brings 
> benefits such as:
>  * We can write unit tests for the UI
>  * We can write integration (e2e, end to end) tests with Cypress or 
> Nightwatch (similar to Selenium, but simpler to run and maintain)
>  * It will be easier to keep the code up to date, as tools like GitHub 
> security bot are able to inspect package.json and look for outdated or 
> libraries with CVE's
>  * It will be easier to incorporate other libraries in the code, so that we 
> can easily switch the JS code for the editor (for example), or add a new 
> library to handle SPARQL, etc
>  * It is now easier to find developers that know Vue, React, Angular, than 
> Backbone (though that was the first framework I learned, and I really like 
> it), so maybe we would get more contributors to help with Fuseki UI
> So features we would have after this issue:
>  * Application built with ES6 JavaScript code
>  * Using Vue.js as framework for the UI
>  * Adding accessibility support (WCAG 2.0, mybe covering section 508 
> though I'm not quite familiar as that's more for US)
>  * Update all the JS libraries
>  * Add documentation to the code with JSDoc (the current code lacks 
> documentation)
>  * Add tests, both unit and end-to-end (also not present in current code)
>  * Maintain the look and feel with Bootstrap, and limit what is changed (i.e. 
> users are already familiar with Fuseki, and know they can upload data, run 
> queries, etc, so we should make sure that they are able to find it)
>  * Theming, with a default light-mode, a dark-mode, and (possibly?) 
> color-blind or other custom themes
>  * Work on mobile/responsive viewports
>  * Local browser settings; this is something cheap, that doesn't require 
> changing to the backend, and would allow us to persist user settings such as:
>  ** Previous executed Queries
>  ** Extra query prefixes
>  ** Number of datasets displayed per page in the main page
>  ** How long the server status widget queries the server (i.e. should we ping 
> it every 1 hour? every 30 seconds?)
>  ** The theme of the user (dark, light, color-blind-protanopia, 
> high-contrast, etc) leveraging bootstrap-vue
>  ** User language



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (JENA-1911) Update Fuseki 2 UI JS code

[Bruno P. Kinoshita (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated JENA-1911:
-
Affects Version/s: Jena 4.3.2
   (was: Jena 3.15.0)

> Update Fuseki 2 UI JS code
> --
>
> Key: JENA-1911
> URL: https://issues.apache.org/jira/browse/JENA-1911
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki
>Affects Versions: Jena 4.3.2
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Attachments: image-2020-06-05-12-09-57-685.png, 
> image-2020-06-05-12-11-01-945.png, image-2020-06-05-12-13-40-428.png, 
> image-2020-06-05-12-15-19-199.png
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The existing Jena Fuseki user interface uses Backbone.js, with extra 
> libraries such as JQuery, Marionette.js. The JavaScript code pre-dates ES6, 
> which is largely supported now.
> This issue is a placeholder for discussion & work around updating the UI. 
> Using ES6 in the code would be a great improvement.
> But I also suggesting adopting a different framework. The most famous 
> framework for JS UI is probably React, followed by Angular & Vue. I am using 
> Vue.js at $work, so I am biased.
> The reason we chose Vue.js at work is that the development team is using 
> mainly Python, with background in Perl, C, and Shell. So out of the three, 
> Vue.js was the simplest, as it didn't require TypeScript, special syntax, and 
> the tools required to build an app with Vue are also quite simple.
> One downside of this approach is the build of Apache Jena, which would 
> require Node.js and a build tool like Yarn or NPM. But it also brings 
> benefits such as:
>  * We can write unit tests for the UI
>  * We can write integration (e2e, end to end) tests with Cypress or 
> Nightwatch (similar to Selenium, but simpler to run and maintain)
>  * It will be easier to keep the code up to date, as tools like GitHub 
> security bot are able to inspect package.json and look for outdated or 
> libraries with CVE's
>  * It will be easier to incorporate other libraries in the code, so that we 
> can easily switch the JS code for the editor (for example), or add a new 
> library to handle SPARQL, etc
>  * It is now easier to find developers that know Vue, React, Angular, than 
> Backbone (though that was the first framework I learned, and I really like 
> it), so maybe we would get more contributors to help with Fuseki UI
> So features we would have after this issue:
>  * Application built with ES6 JavaScript code
>  * Using Vue.js as framework for the UI
>  * Adding accessibility support (WCAG 2.0, mybe covering section 508 
> though I'm not quite familiar as that's more for US)
>  * Update all the JS libraries
>  * Add documentation to the code with JSDoc (the current code lacks 
> documentation)
>  * Add tests, both unit and end-to-end (also not present in current code)
>  * Maintain the look and feel with Bootstrap, and limit what is changed (i.e. 
> users are already familiar with Fuseki, and know they can upload data, run 
> queries, etc, so we should make sure that they are able to find it)
>  * Theming, with a default light-mode, a dark-mode, and (possibly?) 
> color-blind or other custom themes
>  * Work on mobile/responsive viewports
>  * Local browser settings; this is something cheap, that doesn't require 
> changing to the backend, and would allow us to persist user settings such as:
>  ** Previous executed Queries
>  ** Extra query prefixes
>  ** Number of datasets displayed per page in the main page
>  ** How long the server status widget queries the server (i.e. should we ping 
> it every 1 hour? every 30 seconds?)
>  ** The theme of the user (dark, light, color-blind-protanopia, 
> high-contrast, etc) leveraging bootstrap-vue
>  ** User language



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (JENA-1911) Update Fuseki 2 UI JS code

[Bruno P. Kinoshita (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated JENA-1911:
-
Fix Version/s: Jena 4.4.0

> Update Fuseki 2 UI JS code
> --
>
> Key: JENA-1911
> URL: https://issues.apache.org/jira/browse/JENA-1911
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki
>Affects Versions: Jena 4.3.2
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: Jena 4.4.0
>
> Attachments: image-2020-06-05-12-09-57-685.png, 
> image-2020-06-05-12-11-01-945.png, image-2020-06-05-12-13-40-428.png, 
> image-2020-06-05-12-15-19-199.png
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The existing Jena Fuseki user interface uses Backbone.js, with extra 
> libraries such as JQuery, Marionette.js. The JavaScript code pre-dates ES6, 
> which is largely supported now.
> This issue is a placeholder for discussion & work around updating the UI. 
> Using ES6 in the code would be a great improvement.
> But I also suggesting adopting a different framework. The most famous 
> framework for JS UI is probably React, followed by Angular & Vue. I am using 
> Vue.js at $work, so I am biased.
> The reason we chose Vue.js at work is that the development team is using 
> mainly Python, with background in Perl, C, and Shell. So out of the three, 
> Vue.js was the simplest, as it didn't require TypeScript, special syntax, and 
> the tools required to build an app with Vue are also quite simple.
> One downside of this approach is the build of Apache Jena, which would 
> require Node.js and a build tool like Yarn or NPM. But it also brings 
> benefits such as:
>  * We can write unit tests for the UI
>  * We can write integration (e2e, end to end) tests with Cypress or 
> Nightwatch (similar to Selenium, but simpler to run and maintain)
>  * It will be easier to keep the code up to date, as tools like GitHub 
> security bot are able to inspect package.json and look for outdated or 
> libraries with CVE's
>  * It will be easier to incorporate other libraries in the code, so that we 
> can easily switch the JS code for the editor (for example), or add a new 
> library to handle SPARQL, etc
>  * It is now easier to find developers that know Vue, React, Angular, than 
> Backbone (though that was the first framework I learned, and I really like 
> it), so maybe we would get more contributors to help with Fuseki UI
> So features we would have after this issue:
>  * Application built with ES6 JavaScript code
>  * Using Vue.js as framework for the UI
>  * Adding accessibility support (WCAG 2.0, mybe covering section 508 
> though I'm not quite familiar as that's more for US)
>  * Update all the JS libraries
>  * Add documentation to the code with JSDoc (the current code lacks 
> documentation)
>  * Add tests, both unit and end-to-end (also not present in current code)
>  * Maintain the look and feel with Bootstrap, and limit what is changed (i.e. 
> users are already familiar with Fuseki, and know they can upload data, run 
> queries, etc, so we should make sure that they are able to find it)
>  * Theming, with a default light-mode, a dark-mode, and (possibly?) 
> color-blind or other custom themes
>  * Work on mobile/responsive viewports
>  * Local browser settings; this is something cheap, that doesn't require 
> changing to the backend, and would allow us to persist user settings such as:
>  ** Previous executed Queries
>  ** Extra query prefixes
>  ** Number of datasets displayed per page in the main page
>  ** How long the server status widget queries the server (i.e. should we ping 
> it every 1 hour? every 30 seconds?)
>  ** The theme of the user (dark, light, color-blind-protanopia, 
> high-contrast, etc) leveraging bootstrap-vue
>  ** User language



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JENA-1911) Update Fuseki 2 UI JS code

[Bruno P. Kinoshita (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17463118#comment-17463118
 ] 

Bruno P. Kinoshita commented on JENA-1911:
--

Re-opened, updated versions, and marked as resolved.

> Update Fuseki 2 UI JS code
> --
>
> Key: JENA-1911
> URL: https://issues.apache.org/jira/browse/JENA-1911
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki
>Affects Versions: Jena 4.3.2
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: Jena 4.4.0
>
> Attachments: image-2020-06-05-12-09-57-685.png, 
> image-2020-06-05-12-11-01-945.png, image-2020-06-05-12-13-40-428.png, 
> image-2020-06-05-12-15-19-199.png
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The existing Jena Fuseki user interface uses Backbone.js, with extra 
> libraries such as JQuery, Marionette.js. The JavaScript code pre-dates ES6, 
> which is largely supported now.
> This issue is a placeholder for discussion & work around updating the UI. 
> Using ES6 in the code would be a great improvement.
> But I also suggesting adopting a different framework. The most famous 
> framework for JS UI is probably React, followed by Angular & Vue. I am using 
> Vue.js at $work, so I am biased.
> The reason we chose Vue.js at work is that the development team is using 
> mainly Python, with background in Perl, C, and Shell. So out of the three, 
> Vue.js was the simplest, as it didn't require TypeScript, special syntax, and 
> the tools required to build an app with Vue are also quite simple.
> One downside of this approach is the build of Apache Jena, which would 
> require Node.js and a build tool like Yarn or NPM. But it also brings 
> benefits such as:
>  * We can write unit tests for the UI
>  * We can write integration (e2e, end to end) tests with Cypress or 
> Nightwatch (similar to Selenium, but simpler to run and maintain)
>  * It will be easier to keep the code up to date, as tools like GitHub 
> security bot are able to inspect package.json and look for outdated or 
> libraries with CVE's
>  * It will be easier to incorporate other libraries in the code, so that we 
> can easily switch the JS code for the editor (for example), or add a new 
> library to handle SPARQL, etc
>  * It is now easier to find developers that know Vue, React, Angular, than 
> Backbone (though that was the first framework I learned, and I really like 
> it), so maybe we would get more contributors to help with Fuseki UI
> So features we would have after this issue:
>  * Application built with ES6 JavaScript code
>  * Using Vue.js as framework for the UI
>  * Adding accessibility support (WCAG 2.0, mybe covering section 508 
> though I'm not quite familiar as that's more for US)
>  * Update all the JS libraries
>  * Add documentation to the code with JSDoc (the current code lacks 
> documentation)
>  * Add tests, both unit and end-to-end (also not present in current code)
>  * Maintain the look and feel with Bootstrap, and limit what is changed (i.e. 
> users are already familiar with Fuseki, and know they can upload data, run 
> queries, etc, so we should make sure that they are able to find it)
>  * Theming, with a default light-mode, a dark-mode, and (possibly?) 
> color-blind or other custom themes
>  * Work on mobile/responsive viewports
>  * Local browser settings; this is something cheap, that doesn't require 
> changing to the backend, and would allow us to persist user settings such as:
>  ** Previous executed Queries
>  ** Extra query prefixes
>  ** Number of datasets displayed per page in the main page
>  ** How long the server status widget queries the server (i.e. should we ping 
> it every 1 hour? every 30 seconds?)
>  ** The theme of the user (dark, light, color-blind-protanopia, 
> high-contrast, etc) leveraging bootstrap-vue
>  ** User language



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (JENA-2260) UI: build is modifying yarn.lock

[Bruno P. Kinoshita (Jira)]

Bruno P. Kinoshita created JENA-2260:


 Summary: UI: build is modifying yarn.lock
 Key: JENA-2260
 URL: https://issues.apache.org/jira/browse/JENA-2260
 Project: Apache Jena
  Issue Type: Bug
Affects Versions: Jena 4.3.2
Reporter: Bruno P. Kinoshita
Assignee: Bruno P. Kinoshita
 Fix For: Jena 4.4.0


Context: [https://lists.apache.org/thread/7qnw60pjtkbrz4gws0hx1zs3wx1cn4yp]

Fix is bumping Yarn used by the Maven plug-in from 0.16 to 1.22.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (JENA-2261) UI: add unit tests

[Bruno P. Kinoshita (Jira)]

Bruno P. Kinoshita created JENA-2261:


 Summary: UI: add unit tests
 Key: JENA-2261
 URL: https://issues.apache.org/jira/browse/JENA-2261
 Project: Apache Jena
  Issue Type: Improvement
  Components: Fuseki
Affects Versions: Jena 4.3.2
Reporter: Bruno P. Kinoshita
Assignee: Bruno P. Kinoshita
 Fix For: Jena 4.4.0


Unit tests in JS for the new UI. Not a blocker as the app is small and we can 
manually cover most of the code functions. So not a problem if its FixVersion 
is bumped to the next-next release.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (JENA-2260) UI: build is modifying yarn.lock

[Bruno P. Kinoshita (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita resolved JENA-2260.
--
Resolution: Fixed

> UI: build is modifying yarn.lock
> 
>
> Key: JENA-2260
> URL: https://issues.apache.org/jira/browse/JENA-2260
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 4.3.2
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: Jena 4.4.0
>
>
> Context: [https://lists.apache.org/thread/7qnw60pjtkbrz4gws0hx1zs3wx1cn4yp]
> Fix is bumping Yarn used by the Maven plug-in from 0.16 to 1.22.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (JENA-2263) Upgrade UI dependencies

[Bruno P. Kinoshita (Jira)]

Bruno P. Kinoshita created JENA-2263:


 Summary: Upgrade UI dependencies
 Key: JENA-2263
 URL: https://issues.apache.org/jira/browse/JENA-2263
 Project: Apache Jena
  Issue Type: Improvement
  Components: Fuseki
Affects Versions: Jena 4.3.2
Reporter: Bruno P. Kinoshita
Assignee: Bruno P. Kinoshita
 Fix For: Jena 4.4.0






--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (JENA-2263) Upgrade UI dependencies

[Bruno P. Kinoshita (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated JENA-2263:
-
Description: 
 @triply/yasr                ^4.2.20  →  ^4.2.21     
 axios                       ^0.24.0  →  ^0.25.0     
 core-js                     ^3.20.2  →  ^3.20.3     
 @vue/cli-plugin-unit-mocha   ~4.5.0  →  ~4.5.15     
 chai                         ^4.3.4  →   ^4.3.6     
 eslint-plugin-import        ^2.25.3  →  ^2.25.4     
 eslint-plugin-vue            ^8.2.0  →   ^8.4.0     
 sass                        ^1.45.2  →  ^1.49.0    

> Upgrade UI dependencies
> ---
>
> Key: JENA-2263
> URL: https://issues.apache.org/jira/browse/JENA-2263
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki
>Affects Versions: Jena 4.3.2
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: Jena 4.4.0
>
>
>  @triply/yasr                ^4.2.20  →  ^4.2.21     
>  axios                       ^0.24.0  →  ^0.25.0     
>  core-js                     ^3.20.2  →  ^3.20.3     
>  @vue/cli-plugin-unit-mocha   ~4.5.0  →  ~4.5.15     
>  chai                         ^4.3.4  →   ^4.3.6     
>  eslint-plugin-import        ^2.25.3  →  ^2.25.4     
>  eslint-plugin-vue            ^8.2.0  →   ^8.4.0     
>  sass                        ^1.45.2  →  ^1.49.0    



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (JENA-2263) Upgrade UI dependencies

[Bruno P. Kinoshita (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated JENA-2263:
-
Description: 
{noformat}
 @triply/yasr                ^4.2.20  →  ^4.2.21     
 axios                       ^0.24.0  →  ^0.25.0     
 core-js                     ^3.20.2  →  ^3.20.3     
 @vue/cli-plugin-unit-mocha   ~4.5.0  →  ~4.5.15     
 chai                         ^4.3.4  →   ^4.3.6     
 eslint-plugin-import        ^2.25.3  →  ^2.25.4     
 eslint-plugin-vue            ^8.2.0  →   ^8.4.0     
 sass                        ^1.45.2  →  ^1.49.0    {noformat}
 

  was:
 @triply/yasr                ^4.2.20  →  ^4.2.21     
 axios                       ^0.24.0  →  ^0.25.0     
 core-js                     ^3.20.2  →  ^3.20.3     
 @vue/cli-plugin-unit-mocha   ~4.5.0  →  ~4.5.15     
 chai                         ^4.3.4  →   ^4.3.6     
 eslint-plugin-import        ^2.25.3  →  ^2.25.4     
 eslint-plugin-vue            ^8.2.0  →   ^8.4.0     
 sass                        ^1.45.2  →  ^1.49.0    


> Upgrade UI dependencies
> ---
>
> Key: JENA-2263
> URL: https://issues.apache.org/jira/browse/JENA-2263
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki
>Affects Versions: Jena 4.3.2
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: Jena 4.4.0
>
>
> {noformat}
>  @triply/yasr                ^4.2.20  →  ^4.2.21     
>  axios                       ^0.24.0  →  ^0.25.0     
>  core-js                     ^3.20.2  →  ^3.20.3     
>  @vue/cli-plugin-unit-mocha   ~4.5.0  →  ~4.5.15     
>  chai                         ^4.3.4  →   ^4.3.6     
>  eslint-plugin-import        ^2.25.3  →  ^2.25.4     
>  eslint-plugin-vue            ^8.2.0  →   ^8.4.0     
>  sass                        ^1.45.2  →  ^1.49.0    {noformat}
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (JENA-2265) UI: fix Fuseki URL's when using the UI in Tomcat

[Bruno P. Kinoshita (Jira)]

Bruno P. Kinoshita created JENA-2265:


 Summary: UI: fix Fuseki URL's when using the UI in Tomcat
 Key: JENA-2265
 URL: https://issues.apache.org/jira/browse/JENA-2265
 Project: Apache Jena
  Issue Type: Bug
  Components: Fuseki
Affects Versions: Jena 4.3.2
Reporter: Bruno P. Kinoshita
Assignee: Bruno P. Kinoshita
 Fix For: Jena 4.4.0


Context: 
{color:#8c8c8c}[https://lists.apache.org/thread/z3gb5w95oc7c4v0g1jpk9jkxm0l4b7lh]{color}

The UI was creating URL's for Fuseki starting with `/` without taking into 
consideration the paths when deployed on Tomcat.

Also, the static resources were not being retrieved from correct URL.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JENA-2270) Improve Fuseki data upload functionality.

[Bruno P. Kinoshita (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486192#comment-17486192
 ] 

Bruno P. Kinoshita commented on JENA-2270:
--

>The UI "add data" tab uses GSP style to load data.

So that means there is no work in the UI? Is it only removing code that's not 
used anymore?

> Improve Fuseki data upload functionality.
> -
>
> Key: JENA-2270
> URL: https://issues.apache.org/jira/browse/JENA-2270
> Project: Apache Jena
>  Issue Type: Improvement
>Affects Versions: Jena 4.4.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
>
> Continues JENA-2248.
> The upload code has become messy with duplication. 
> Functionality for HTML file upload {{}} has a dependency 
> on code using {{javax}}, and not {{jakarta}}.
> {{HTML_FileUpload}} is dated and it buffers its input.
> This is a step towards having the option to remove HTML file upload 
> capability.
> A new general data uploader for sending data to a dataset will cover the 
> functionality better.
> The only use of HTML file upload not covered is when the graph name is in the 
> multipart content. This predates SPARQL Graph Store Protocol which is a 
> better approach because the graph name is available at the start and so the 
> data can transactionally stream to the right destination. HTML file upload 
> can, in theory, supply the graph name after the data.
> The UI "add data" tab uses GSP style to load data.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JENA-2271) Fuseki UI: Uploading a triples file to a named graph is "Bad Request".

[Bruno P. Kinoshita (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486194#comment-17486194
 ] 

Bruno P. Kinoshita commented on JENA-2271:
--

I can try to reproduce over the next days and prepare a fix if it's an issue in 
the UI. I think I only tested with random/dummy graph names like default, test.

I think before jumping on suggesting changes/improvements for the UI, I will 
write some functional tests. These should work with and without the backend, 
and will cover things like file upload, graph creation, queries, etc.

> Fuseki UI: Uploading a triples file to a named graph is "Bad Request".
> --
>
> Key: JENA-2271
> URL: https://issues.apache.org/jira/browse/JENA-2271
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 4.4.0
>Reporter: Andy Seaborne
>Priority: Major
>
> On the "add data" tab, if the graph name is set to "http://example/graphname"; 
> in the UI, a file upload to the server returns "400 Bad request".
> Chrome dev tools show the POST as:
> {noformat}
> http://localhost:3030/ds/data?graph=http:/example/graphname
> {noformat}
> The request ends up as {{?graph=http:/example/graphname}} with one slash.
> Using three /// in the graph name also produces a single-slash {{{}graph={}}}.
> Using {{http:%2F/example/graphname}} does send the data successfully to the 
> named graph.
> (This is not an encoding issue - the query string is right without encoding. 
> "{{/}}" and "{{:}}" are valid in the query string of a URI.)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (JENA-2271) Fuseki UI: Uploading a triples file to a named graph is "Bad Request".

[Bruno P. Kinoshita (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita reassigned JENA-2271:


Assignee: Bruno P. Kinoshita

> Fuseki UI: Uploading a triples file to a named graph is "Bad Request".
> --
>
> Key: JENA-2271
> URL: https://issues.apache.org/jira/browse/JENA-2271
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 4.4.0
>Reporter: Andy Seaborne
>Assignee: Bruno P. Kinoshita
>Priority: Major
>
> On the "add data" tab, if the graph name is set to "http://example/graphname"; 
> in the UI, a file upload to the server returns "400 Bad request".
> Chrome dev tools show the POST as:
> {noformat}
> http://localhost:3030/ds/data?graph=http:/example/graphname
> {noformat}
> The request ends up as {{?graph=http:/example/graphname}} with one slash.
> Using three /// in the graph name also produces a single-slash {{{}graph={}}}.
> Using {{http:%2F/example/graphname}} does send the data successfully to the 
> named graph.
> (This is not an encoding issue - the query string is right without encoding. 
> "{{/}}" and "{{:}}" are valid in the query string of a URI.)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JENA-2271) Fuseki UI: Uploading a triples file to a named graph is "Bad Request".

[Bruno P. Kinoshita (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487397#comment-17487397
 ] 

Bruno P. Kinoshita commented on JENA-2271:
--

Reproduced. I added some code to remove double slashes from URL, starting from 
the query path... but forgot about valid double slashes in the Graph Name. 
Sorry! PR submitted (with unit tests)

> Fuseki UI: Uploading a triples file to a named graph is "Bad Request".
> --
>
> Key: JENA-2271
> URL: https://issues.apache.org/jira/browse/JENA-2271
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 4.4.0
>Reporter: Andy Seaborne
>Assignee: Bruno P. Kinoshita
>Priority: Major
>
> On the "add data" tab, if the graph name is set to "http://example/graphname"; 
> in the UI, a file upload to the server returns "400 Bad request".
> Chrome dev tools show the POST as:
> {noformat}
> http://localhost:3030/ds/data?graph=http:/example/graphname
> {noformat}
> The request ends up as {{?graph=http:/example/graphname}} with one slash.
> Using three /// in the graph name also produces a single-slash {{{}graph={}}}.
> Using {{http:%2F/example/graphname}} does send the data successfully to the 
> named graph.
> (This is not an encoding issue - the query string is right without encoding. 
> "{{/}}" and "{{:}}" are valid in the query string of a URI.)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (JENA-2271) Fuseki UI: Uploading a triples file to a named graph is "Bad Request".

[Bruno P. Kinoshita (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita resolved JENA-2271.
--
Fix Version/s: Jena 4.5.0
   Resolution: Fixed

> Fuseki UI: Uploading a triples file to a named graph is "Bad Request".
> --
>
> Key: JENA-2271
> URL: https://issues.apache.org/jira/browse/JENA-2271
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 4.4.0
>Reporter: Andy Seaborne
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Jena 4.5.0
>
>
> On the "add data" tab, if the graph name is set to "http://example/graphname"; 
> in the UI, a file upload to the server returns "400 Bad request".
> Chrome dev tools show the POST as:
> {noformat}
> http://localhost:3030/ds/data?graph=http:/example/graphname
> {noformat}
> The request ends up as {{?graph=http:/example/graphname}} with one slash.
> Using three /// in the graph name also produces a single-slash {{{}graph={}}}.
> Using {{http:%2F/example/graphname}} does send the data successfully to the 
> named graph.
> (This is not an encoding issue - the query string is right without encoding. 
> "{{/}}" and "{{:}}" are valid in the query string of a URI.)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JENA-2282) Fuseki2 Query Store

[Bruno P. Kinoshita (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492376#comment-17492376
 ] 

Bruno P. Kinoshita commented on JENA-2282:
--

Great idea IMO! I keep looking for queries to list GRAPHs, or to delete all 
graphs (when testing the UI or Jena issues), or when working on something like 
Skosmos. Being able to save these queries in Fuseki UI would save me a good 
amount of time :) So my +1 (even better if you can sponsor some co-workers to 
work on this!!!). Thanks.

> Fuseki2 Query Store
> ---
>
> Key: JENA-2282
> URL: https://issues.apache.org/jira/browse/JENA-2282
> Project: Apache Jena
>  Issue Type: Wish
>  Components: Fuseki UI
>Affects Versions: Jena 4.4.0
>Reporter: Nicholas
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> Many triplestore applications have a way to store SPARQL queries. These sorts 
> of application parts are really useful: you can keep coming back to useful 
> queries. If the queries can be named, then you can build up a query library.
> Not hard to make and super useful. Unless there is already an extension for 
> this or plans for such, I'm happy to (have my staff) give this a go!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (JENA-2283) Allow setting the SPARQL endpoint.

[Bruno P. Kinoshita (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita reassigned JENA-2283:


Assignee: Bruno P. Kinoshita

> Allow setting the SPARQL endpoint.
> --
>
> Key: JENA-2283
> URL: https://issues.apache.org/jira/browse/JENA-2283
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki UI
>Affects Versions: Jena 4.4.0
>Reporter: Andy Seaborne
>Assignee: Bruno P. Kinoshita
>Priority: Major
>
> The old UI had a "SPARQL endpoint" box.
> That would be useful for plugging the UI into any SPARQL endpoint without 
> relying on introspection of the server.
> As reported: 
> https://stackoverflow.com/questions/7989/fuseki-4-4-ui-set-endpoint-for-update-queries,
>  it is also a "trick" for setting the endpoint to the update service and 
> sending SPARQL Update.
> The old API sets the HTML form parameter correctly - probably yasgui knows 
> whether it is a query string or an update string and sets the HTML form 
> parameter correctly ({{query=}} or {{update=}}) for 
> {{application/x-www-form-urlencoded}}.
> 
> In Fuseki, if a request goes to a named service ("/dataset/query", 
> "/dataset/update") the service will execute it without being too worried 
> about the content -type. Sending to "/dataset" does require a content type or 
> correct HTML form parameter.
> {noformat}
> curl -XPOST -H 'Content-type: ' --data 'INSERTDATA {   }' 
> http://localhost:3030/ds/update
> {noformat}
> works - the {{-H 'Content-type: '}} turns off curl adding 
> {{application/x-www-form-urlencoded}}.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JENA-2282) Fuseki2 Query Store

[Bruno P. Kinoshita (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493603#comment-17493603
 ] 

Bruno P. Kinoshita commented on JENA-2282:
--

As far as I know these settings are read from the assembler to create from a 
config. Then in Fuseki you can look at the servlets to see how it's loaded, 
e.g. 
[https://github.com/apache/jena/blob/31dc0d328c4858401e5d3fa99702c97eba0383a0/jena-fuseki2/jena-fuseki-webapp/src/main/java/org/apache/jena/fuseki/webapp/FusekiWebapp.java#L218]

Every time you start the Tomcat server, or Jetty container, they will start the 
application listeners, that will reload the configuration from disk (or from 
command line arguments). But as far as I know these routines need to read 
assemblers from disk first, to then know where to load the datasets from, what 
settings these are using, etc.

> Fuseki2 Query Store
> ---
>
> Key: JENA-2282
> URL: https://issues.apache.org/jira/browse/JENA-2282
> Project: Apache Jena
>  Issue Type: Wish
>  Components: Fuseki UI
>Affects Versions: Jena 4.4.0
>Reporter: Nicholas
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> Many triplestore applications have a way to store SPARQL queries. These sorts 
> of application parts are really useful: you can keep coming back to useful 
> queries. If the queries can be named, then you can build up a query library.
> Not hard to make and super useful. Unless there is already an extension for 
> this or plans for such, I'm happy to (have my staff) give this a go!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JENA-2283) Allow setting the SPARQL endpoint.

[Bruno P. Kinoshita (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493890#comment-17493890
 ] 

Bruno P. Kinoshita commented on JENA-2283:
--

Oh, now I remember seeing that input field, and not understanding why that'd be 
useful, thought it was not used/unnecessary. Sorry.

Note to self, here's what it looked like (screenshot).

 

> Allow setting the SPARQL endpoint.
> --
>
> Key: JENA-2283
> URL: https://issues.apache.org/jira/browse/JENA-2283
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki UI
>Affects Versions: Jena 4.4.0
>Reporter: Andy Seaborne
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: Screenshot from 2022-02-18 00-32-20.png
>
>
> The old UI had a "SPARQL endpoint" box.
> That would be useful for plugging the UI into any SPARQL endpoint without 
> relying on introspection of the server.
> As reported: 
> https://stackoverflow.com/questions/7989/fuseki-4-4-ui-set-endpoint-for-update-queries,
>  it is also a "trick" for setting the endpoint to the update service and 
> sending SPARQL Update.
> The old API sets the HTML form parameter correctly - probably yasgui knows 
> whether it is a query string or an update string and sets the HTML form 
> parameter correctly ({{query=}} or {{update=}}) for 
> {{application/x-www-form-urlencoded}}.
> 
> In Fuseki, if a request goes to a named service ("/dataset/query", 
> "/dataset/update") the service will execute it without being too worried 
> about the content -type. Sending to "/dataset" does require a content type or 
> correct HTML form parameter.
> {noformat}
> curl -XPOST -H 'Content-type: ' --data 'INSERTDATA {   }' 
> http://localhost:3030/ds/update
> {noformat}
> works - the {{-H 'Content-type: '}} turns off curl adding 
> {{application/x-www-form-urlencoded}}.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (JENA-2283) Allow setting the SPARQL endpoint.

[Bruno P. Kinoshita (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated JENA-2283:
-
Attachment: Screenshot from 2022-02-18 00-32-20.png

> Allow setting the SPARQL endpoint.
> --
>
> Key: JENA-2283
> URL: https://issues.apache.org/jira/browse/JENA-2283
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki UI
>Affects Versions: Jena 4.4.0
>Reporter: Andy Seaborne
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: Screenshot from 2022-02-18 00-32-20.png
>
>
> The old UI had a "SPARQL endpoint" box.
> That would be useful for plugging the UI into any SPARQL endpoint without 
> relying on introspection of the server.
> As reported: 
> https://stackoverflow.com/questions/7989/fuseki-4-4-ui-set-endpoint-for-update-queries,
>  it is also a "trick" for setting the endpoint to the update service and 
> sending SPARQL Update.
> The old API sets the HTML form parameter correctly - probably yasgui knows 
> whether it is a query string or an update string and sets the HTML form 
> parameter correctly ({{query=}} or {{update=}}) for 
> {{application/x-www-form-urlencoded}}.
> 
> In Fuseki, if a request goes to a named service ("/dataset/query", 
> "/dataset/update") the service will execute it without being too worried 
> about the content -type. Sending to "/dataset" does require a content type or 
> correct HTML form parameter.
> {noformat}
> curl -XPOST -H 'Content-type: ' --data 'INSERTDATA {   }' 
> http://localhost:3030/ds/update
> {noformat}
> works - the {{-H 'Content-type: '}} turns off curl adding 
> {{application/x-www-form-urlencoded}}.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JENA-2282) Fuseki2 Query Store

[Bruno P. Kinoshita (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494475#comment-17494475
 ] 

Bruno P. Kinoshita commented on JENA-2282:
--

Definitely doable [~LorenzB] . Good suggestion. it might be challenging to 
persist the state of tabs & queries if users want it. But that's a good 
discussion for a separate issue. Could you create a separate issue for that 
[~LorenzB] ? Thanks!

> Fuseki2 Query Store
> ---
>
> Key: JENA-2282
> URL: https://issues.apache.org/jira/browse/JENA-2282
> Project: Apache Jena
>  Issue Type: Wish
>  Components: Fuseki UI
>Affects Versions: Jena 4.4.0
>Reporter: Nicholas
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> Many triplestore applications have a way to store SPARQL queries. These sorts 
> of application parts are really useful: you can keep coming back to useful 
> queries. If the queries can be named, then you can build up a query library.
> Not hard to make and super useful. Unless there is already an extension for 
> this or plans for such, I'm happy to (have my staff) give this a go!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (JENA-2283) Allow setting the SPARQL endpoint.

[Bruno P. Kinoshita (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita resolved JENA-2283.
--
Fix Version/s: Jena 4.5.0
   Resolution: Fixed

> Allow setting the SPARQL endpoint.
> --
>
> Key: JENA-2283
> URL: https://issues.apache.org/jira/browse/JENA-2283
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki UI
>Affects Versions: Jena 4.4.0
>Reporter: Andy Seaborne
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Jena 4.5.0
>
> Attachments: Screenshot from 2022-02-18 00-32-20.png
>
>
> The old UI had a "SPARQL endpoint" box.
> That would be useful for plugging the UI into any SPARQL endpoint without 
> relying on introspection of the server.
> As reported: 
> https://stackoverflow.com/questions/7989/fuseki-4-4-ui-set-endpoint-for-update-queries,
>  it is also a "trick" for setting the endpoint to the update service and 
> sending SPARQL Update.
> The old API sets the HTML form parameter correctly - probably yasgui knows 
> whether it is a query string or an update string and sets the HTML form 
> parameter correctly ({{query=}} or {{update=}}) for 
> {{application/x-www-form-urlencoded}}.
> 
> In Fuseki, if a request goes to a named service ("/dataset/query", 
> "/dataset/update") the service will execute it without being too worried 
> about the content -type. Sending to "/dataset" does require a content type or 
> correct HTML form parameter.
> {noformat}
> curl -XPOST -H 'Content-type: ' --data 'INSERTDATA {   }' 
> http://localhost:3030/ds/update
> {noformat}
> works - the {{-H 'Content-type: '}} turns off curl adding 
> {{application/x-www-form-urlencoded}}.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (JENA-2295) UI: Query share feature broken in the new UI

[Bruno P. Kinoshita (Jira)]

Bruno P. Kinoshita created JENA-2295:


 Summary: UI: Query share feature broken in the new UI
 Key: JENA-2295
 URL: https://issues.apache.org/jira/browse/JENA-2295
 Project: Apache Jena
  Issue Type: Bug
  Components: Fuseki UI
Affects Versions: Jena 4.4.0
Reporter: Bruno P. Kinoshita
Assignee: Bruno P. Kinoshita


Reported in the users mailing list. This is a feature of the YASGUI set of 
libraries. You have an icon next to the Run/Play icon in the query editor. That 
icon shows a share-URL to be copied.

Looks like we are encoding it one time too many, or maybe missing something 
else. But it shouldn't be too hard to fix.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (JENA-2295) UI: Query share feature broken in the new UI

[Bruno P. Kinoshita (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated JENA-2295:
-
Attachment: image-2022-03-01-17-33-17-591.png

> UI: Query share feature broken in the new UI
> 
>
> Key: JENA-2295
> URL: https://issues.apache.org/jira/browse/JENA-2295
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki UI
>Affects Versions: Jena 4.4.0
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Attachments: image-2022-03-01-17-33-17-591.png
>
>
> Reported in the users mailing list. This is a feature of the YASGUI set of 
> libraries. You have an icon next to the Run/Play icon in the query editor. 
> That icon shows a share-URL to be copied.
> Looks like we are encoding it one time too many, or maybe missing something 
> else. But it shouldn't be too hard to fix.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JENA-2295) UI: Query share feature broken in the new UI

[Bruno P. Kinoshita (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499327#comment-17499327
 ] 

Bruno P. Kinoshita commented on JENA-2295:
--

The white page reported in the users mailing list is actually a 404 page. We 
can do better at handling 404 pages, so let's start with a simple page that 
suggests the user to go back to the home link.

 

!image-2022-03-01-17-33-17-591.png|width=597,height=263!

> UI: Query share feature broken in the new UI
> 
>
> Key: JENA-2295
> URL: https://issues.apache.org/jira/browse/JENA-2295
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki UI
>Affects Versions: Jena 4.4.0
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Attachments: image-2022-03-01-17-33-17-591.png
>
>
> Reported in the users mailing list. This is a feature of the YASGUI set of 
> libraries. You have an icon next to the Run/Play icon in the query editor. 
> That icon shows a share-URL to be copied.
> Looks like we are encoding it one time too many, or maybe missing something 
> else. But it shouldn't be too hard to fix.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (JENA-2295) UI: Query share feature broken in the new UI

[Bruno P. Kinoshita (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated JENA-2295:
-
Fix Version/s: Jena 4.5.0

> UI: Query share feature broken in the new UI
> 
>
> Key: JENA-2295
> URL: https://issues.apache.org/jira/browse/JENA-2295
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki UI
>Affects Versions: Jena 4.4.0
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: Jena 4.5.0
>
> Attachments: image-2022-03-01-17-33-17-591.png
>
>
> Reported in the users mailing list. This is a feature of the YASGUI set of 
> libraries. You have an icon next to the Run/Play icon in the query editor. 
> That icon shows a share-URL to be copied.
> Looks like we are encoding it one time too many, or maybe missing something 
> else. But it shouldn't be too hard to fix.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Deleted] (JENA-2296) Tips To Choose The Best B.Ed Colleges In Rajasthan

[Bruno P. Kinoshita (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita deleted JENA-2296:
-


> Tips To Choose The Best B.Ed Colleges In Rajasthan
> --
>
> Key: JENA-2296
> URL: https://issues.apache.org/jira/browse/JENA-2296
> Project: Apache Jena
>  Issue Type: Bug
>Reporter: jaipurjnu
>Priority: Major
>
> If you are looking forward to pursuing a degree in B.Ed from the best [*B Ed 
> Colleges in 
> Rajasthan*|https://www.jnujaipur.ac.in/programmes/ug-programmes/bed], you 
> have arrived at the right location. In this article, we are going to tell you 
> how to apply to the right college and what to do in order to ensure that you 
> get selected for admission to the college in the best way without any hassle. 
> With the help of our tips, there is no doubt that you will be selected in any 
> college that you apply to for the B.Ed degree. 
> *How To Get Selected To a B.Ed. College* 
> Do you want to make sure that you are able to build a proper career? Are you 
> interested in teaching the students and shaping the future generation? If so, 
> then choosing to pursue a degree from the [*BA BEd college list in* 
> *Rajasthan*|https://www.jnujaipur.ac.in/programmes/ug-programmes/ba-bed] is 
> going to be the best option for you. But how do you choose the best college 
> for the degree and ensure that you get selected as well? We have some tips 
> that are going to help you out in the best way. 
> Make sure that you do some research on the reputation of the college before 
> you apply for the course. There is information provided about the reputation 
> of the colleges on their website from which you will be able to have more 
> information about the college in the best way. Hence, this is something you 
> definitely need to keep in mind. 
> Also, you need to ensure that the infrastructure, as well as the faculty of 
> the college, is up to the mark. Students need proper guidance if they want to 
> build the best career for themselves. With proper faculty members and better 
> infrastructure, they can achieve that goal in the best way. 
> *Verdict* 
> So, these are some pointers that you definitely need to keep in your mind 
> when you are trying to find the best *B.Ed colleges in Rajasthan* to pursue 
> higher education in the best way without any hassle.  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (JENA-2295) UI: Query share feature broken in the new UI

[Bruno P. Kinoshita (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita resolved JENA-2295.
--
Resolution: Fixed

> UI: Query share feature broken in the new UI
> 
>
> Key: JENA-2295
> URL: https://issues.apache.org/jira/browse/JENA-2295
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki UI
>Affects Versions: Jena 4.4.0
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: Jena 4.5.0
>
> Attachments: image-2022-03-01-17-33-17-591.png
>
>
> Reported in the users mailing list. This is a feature of the YASGUI set of 
> libraries. You have an icon next to the Run/Play icon in the query editor. 
> That icon shows a share-URL to be copied.
> Looks like we are encoding it one time too many, or maybe missing something 
> else. But it shouldn't be too hard to fix.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (JENA-2307) UI: Add e2e tests

[Bruno P. Kinoshita (Jira)]

Bruno P. Kinoshita created JENA-2307:


 Summary: UI: Add e2e tests
 Key: JENA-2307
 URL: https://issues.apache.org/jira/browse/JENA-2307
 Project: Apache Jena
  Issue Type: Test
  Components: Fuseki
Affects Versions: Jena 4.4.0
Reporter: Bruno P. Kinoshita
Assignee: Bruno P. Kinoshita


The unit tests cannot cover parts of the UI. We do not need the backend for 
that, and can just serve mocked responses to get the UI to build the views and 
components, and verify that everything is working OK.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (JENA-2312) UI must use the service endpoint URL

[Bruno P. Kinoshita (Jira)]

Bruno P. Kinoshita created JENA-2312:


 Summary: UI must use the service endpoint URL
 Key: JENA-2312
 URL: https://issues.apache.org/jira/browse/JENA-2312
 Project: Apache Jena
  Issue Type: Bug
  Components: Fuseki UI
Affects Versions: Jena 4.4.0
Reporter: Bruno P. Kinoshita
Assignee: Bruno P. Kinoshita
 Fix For: Jena 4.5.0


Not sure if 4.5.0 or 4.6.0, feel free to bump up the version if a release is in 
progress, please.

I decided to test the PR for GeoSparql - 
[https://github.com/apache/jena/pull/1204]

And used the example Assembler file from 
[https://jena.apache.org/documentation/geosparql/geosparql-assembler.html.] 
Fuseki loaded the Assembler fine. But when I tried to query it, I realized it 
was getting 404 errors.

I hard-coded the `/sparql` in the UI HTTP requests, but the GeoSparql example 
doesn't define an endpoint. The UI must be able to derive the URL from the 
given configuration, instead of using a hard-coded value.

Already fixed the "Info" tab. Now going through the rest of the code to fix it 
:)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (JENA-699) Replace the CSV/TSV parsing with Apache Commons CSV

[Bruno P. Kinoshita (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated JENA-699:

Attachment: JENA-699.patch

Hello, 

*TL;DR*: added commons-csv-1.0 as dependency in pom, removed classes specific 
to the existing parser, but used commons-csv wrapped within the existing parser 
to maintain the API - https://issues.apache.org/jira/browse/JENA-699

I'm using Jena in a project for a customer, and am slowly learning the code 
base and going through existing issues. Since I contribute to commons, I 
thought I'd give it a try to JENA-699.

I started by removing the CSVParser from the project, as well as the whole 
org.apache.jena.atlas.csv package, and then slowly tried to replace it in the 
rest of the code. 

However, I was having to change code in several places, not only in methods 
handling CSV. Because of that I decided to stick with the existing API, but 
wrap the commons-csv component within the existing parser.

As a consequence, the CSVToken, CSVTokenIterator, and CSVTokenType were removed 
and its tests updated. The CSVParser now forwards calls to the commons 
component, and keeps throwing the same CSVParseException.

The commons-csv parser is created as follows to comply with existing tests:

{code:borderStyle=solid}
CSVFormat.EXCEL.withQuote('\'').parse(input);
{code}

With the code from the patch, using the CSV example from \[1\], and the 
following snippet:

{code:borderStyle=solid}
public static void main(String[] args) throws Exception {
LangRIOT csv = new LangCSV (new StringReader("Town,Population\n" + 
"Southton,123000\n" + 
"Northville,654000"), 
"http://example/b";, "", 
ErrorHandlerFactory.getDefaultErrorHandler(),  new 
WriterStreamRDFBlocks(System.out));
csv.parse();
}
{code}

The result is identical before/after patch: 

{code:borderStyle=solid}
_:b0  1 ;
  "Southton" ;
  
"123000"^^ .

_:b1  2 ;
  "Northville" ;
  
"654000"^^ .
{code}

Hope that helps,
Bruno

\[1\] https://www.w3.org/2013/csvw/wiki/CSV2RDF

> Replace the CSV/TSV parsing with Apache Commons CSV
> ---
>
> Key: JENA-699
> URL: https://issues.apache.org/jira/browse/JENA-699
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Priority: Minor
> Attachments: JENA-699.patch
>
>
> When Apache Commons CSV is released, use that and remove the current parsers 
> in favour of a properly written and designed component.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-699) Replace the CSV/TSV parsing with Apache Commons CSV

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133083#comment-14133083
 ] 

Bruno P. Kinoshita commented on JENA-699:
-

Hi Andy, thanks for the quick reply and brief history background on this issue.

> The parser API should not be seen as fixed; it did it's job at the time but 
> it's not really a public contract. The new jena-csv is better off with a 
> solid parser.

While reading the mailing list before submitting the patch I found this project 
within Jena's SVN repo \[1\]. Since if uses the CSVParser, I think no changes 
will be necessary there, but let me know if anything related to this issue 
needs to be ported to that project.

This was my first issue while learning about Jena project structure and code 
base, but now I'll probably bother you guys in the mailing list to work on the 
issue to generate JSON from SPARQL (JENA 632) :)

Thanks!

\[1\] http://svn.apache.org/repos/asf/jena/Experimental/jena-csv/

> Replace the CSV/TSV parsing with Apache Commons CSV
> ---
>
> Key: JENA-699
> URL: https://issues.apache.org/jira/browse/JENA-699
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Attachments: JENA-699.patch
>
>
> When Apache Commons CSV is released, use that and remove the current parsers 
> in favour of a properly written and designed component.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-789) Permission and pages not found errors when fuseki is started non-root

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14153282#comment-14153282
 ] 

Bruno P. Kinoshita commented on JENA-789:
-

Hi, was having a similar message in logs:
{noformat}
12:20:17 INFO  TDB dataset: directory=/var/lib/fuseki/DB
12:20:17 WARN  No such directory for static content: /.
12:20:17 WARN  You may need to set the --pages or --home option to configure 
static content correctly
12:20:17 WARN  No pages directory - ./pages
12:20:17 INFO  Dataset path = /ds
12:20:17 INFO  Fuseki 1.1.0 2014-07-26T18:10:29+0100
12:20:17 INFO  Started 2014/09/30 12:20:17 BRT on port 8080
{noformat}
Manually applied the patch and it fixed the issue! +1

> Permission and pages not found errors when fuseki is started non-root
> -
>
> Key: JENA-789
> URL: https://issues.apache.org/jira/browse/JENA-789
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Fuseki 1.1.0
> Environment: OEL Linux 5
>Reporter: Nicholas Sushkin
> Attachments: jena-789.patch
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> Multiple issues in fuseki init script when fuseki is started as a non-root 
> user (non-empty $FUSEKI_USER)
> 1. When $FUSEKI_DATA_DIR does not exist, it's created as root by the init 
> script and $FUSEKI_USER cannot open the database with FileException
> com.hp.hpl.jena.tdb.base.file.FileException: Failed to open: 
> <$FUSEKI_DATA_DIR>/node2id.idn (mode=rw)  
>
> at 
> com.hp.hpl.jena.tdb.base.file.ChannelManager.open$(ChannelManager.java:82)
>   
> 2. When $FUSEKI_HOME is not the same as the home directory of $FUSEKI_USER, 
> fuseki is unable to find static content, giving warnings such as
> WARN  No such directory for static content: /home/fuseki/.
> WARN  You may need to set the --pages or --home option to configure static 
> content correctly
> WARN  No pages directory - ./pages  
> 3. When run as non-root, the server output is not saved in 
> $FUSEKI_LOGS_STDERROUT



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-786) Links for examples was not working.

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161412#comment-14161412
 ] 

Bruno P. Kinoshita commented on JENA-786:
-

Hello, 

I cloned the GitHub repository but looks like the site code was outside the 
trunk branch in the SVN. I checked out the SVN repository that looks to be the 
source for the website [1].

Although there are some links broken in the Jena website, I think most of them 
were already fixed in the source code. The only one that is broken and hasn't 
been fixed seems to be the example under the larq documentation [2]. However, I 
think it has been discontinued and the module is not even in GitHub (I think). 
So I believe this issue can be closed? :)

In order to find links that haven't been fixed, I used the Eclipse search tool 
and looked for occurrences of the text "https://svn.apache.org/repos/asf/jena/"; 
in *.mdtext files.

[1] https://svn.apache.org/repos/asf/jena/site/trunk/
[2] http://jena.apache.org/documentation/larq/

> Links for examples was not working.
> ---
>
> Key: JENA-786
> URL: https://issues.apache.org/jira/browse/JENA-786
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Web site
>Affects Versions: Jena 2.12.0
> Environment: Site http://jena.apache.org/tutorials/rdf_api.html
>Reporter: Pablo Diego
>Assignee: Andy Seaborne
>  Labels: examples, links
>
> The links for examples was not working. Example: 
> https://svn.apache.org/repos/asf/jena/trunk/jena-core/src-examples/jena/examples/rdf/Tutorial05.java
> Output:
> Not Found
> The requested URL 
> /repos/asf/jena/trunk/jena-core/src-examples/jena/examples/rdf/Tutorial05.java
>  was not found on this server.
> Apache/2.2.25 (Unix) DAV/2 mod_wsgi/3.1 Python/2.7.3 SVN/1.8.1 mod_ssl/2.2.25 
> OpenSSL/1.0.1i Server at svn.apache.org Port 443



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-786) Links for examples was not working.

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14162971#comment-14162971
 ] 

Bruno P. Kinoshita commented on JENA-786:
-

Hi Andy!

Thanks for confirming that LARQ is discontinued. Yesterday I noted, but forgot 
to comment here. There are three files with links to larq at the moment. The 
larq document can be reached by users by going to the ARQ (SPARQL) link under 
the Learn menu section. These three files are accessible from that part of the 
site, with links pointing to larq.

File:./content/documentation/query/arq-query-eval.mdtext
File: ./content/documentation/query/extension.mdtext
File: ./content/documentation/query/library-function.mdtext

Shall we create a new issue for that? I can file an issue and attach a simple 
patch, assuming that all that is needed is just to update the link to jena-text.

Bruno


> Links for examples was not working.
> ---
>
> Key: JENA-786
> URL: https://issues.apache.org/jira/browse/JENA-786
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Web site
>Affects Versions: Jena 2.12.0
> Environment: Site http://jena.apache.org/tutorials/rdf_api.html
>Reporter: Pablo Diego
>Assignee: Andy Seaborne
>  Labels: examples, links
>
> The links for examples was not working. Example: 
> https://svn.apache.org/repos/asf/jena/trunk/jena-core/src-examples/jena/examples/rdf/Tutorial05.java
> Output:
> Not Found
> The requested URL 
> /repos/asf/jena/trunk/jena-core/src-examples/jena/examples/rdf/Tutorial05.java
>  was not found on this server.
> Apache/2.2.25 (Unix) DAV/2 mod_wsgi/3.1 Python/2.7.3 SVN/1.8.1 mod_ssl/2.2.25 
> OpenSSL/1.0.1i Server at svn.apache.org Port 443



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-786) Links for examples was not working.

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14162993#comment-14162993
 ] 

Bruno P. Kinoshita commented on JENA-786:
-

Hi Phillip, 

Thanks, you're right about it. But as Andy mentioned, it has already been fixed 
in the source code, just hasn't been published yet.

> Links for examples was not working.
> ---
>
> Key: JENA-786
> URL: https://issues.apache.org/jira/browse/JENA-786
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Web site
>Affects Versions: Jena 2.12.0
> Environment: Site http://jena.apache.org/tutorials/rdf_api.html
>Reporter: Pablo Diego
>Assignee: Andy Seaborne
>  Labels: examples, links
>
> The links for examples was not working. Example: 
> https://svn.apache.org/repos/asf/jena/trunk/jena-core/src-examples/jena/examples/rdf/Tutorial05.java
> Output:
> Not Found
> The requested URL 
> /repos/asf/jena/trunk/jena-core/src-examples/jena/examples/rdf/Tutorial05.java
>  was not found on this server.
> Apache/2.2.25 (Unix) DAV/2 mod_wsgi/3.1 Python/2.7.3 SVN/1.8.1 mod_ssl/2.2.25 
> OpenSSL/1.0.1i Server at svn.apache.org Port 443



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JENA-799) Add Javadocs to Fuseki servlets and HTTP Action

[Bruno P. Kinoshita (JIRA)]

Bruno P. Kinoshita created JENA-799:
---

 Summary: Add Javadocs to Fuseki servlets and HTTP Action
 Key: JENA-799
 URL: https://issues.apache.org/jira/browse/JENA-799
 Project: Apache Jena
  Issue Type: Improvement
  Components: Fuseki
Reporter: Bruno P. Kinoshita
Priority: Trivial


Added some Javadoc comments that may be useful for newcomers. I had to debug a 
couple of times the work flow from when a SPARQL query comes via Fuseki, and 
noticed the lack of comments in some methods.

The code has been submitted as pull request to https://github.com/apache/jena 
and I've added a comment in the pull request mentioning this issue ID. 

Thanks!
Bruno



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JENA-799) Add Javadocs to Fuseki servlets and HTTP Action

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14168470#comment-14168470
 ] 

Bruno P. Kinoshita edited comment on JENA-799 at 10/12/14 2:14 AM:
---

And the [link to the pull request|https://github.com/apache/jena/pull/7/].


was (Author: kinow):
And the [link to the pull request|https://github.com/apache/jena/pull/7/files].

> Add Javadocs to Fuseki servlets and HTTP Action
> ---
>
> Key: JENA-799
> URL: https://issues.apache.org/jira/browse/JENA-799
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki
>Reporter: Bruno P. Kinoshita
>Priority: Trivial
>  Labels: documentation, javadoc
>
> Added some Javadoc comments that may be useful for newcomers. I had to debug 
> a couple of times the work flow from when a SPARQL query comes via Fuseki, 
> and noticed the lack of comments in some methods.
> The code has been submitted as pull request to https://github.com/apache/jena 
> and I've added a comment in the pull request mentioning this issue ID. 
> Thanks!
> Bruno



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-799) Add Javadocs to Fuseki servlets and HTTP Action

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14168470#comment-14168470
 ] 

Bruno P. Kinoshita commented on JENA-799:
-

And the [link to the pull request|https://github.com/apache/jena/pull/7/files].

> Add Javadocs to Fuseki servlets and HTTP Action
> ---
>
> Key: JENA-799
> URL: https://issues.apache.org/jira/browse/JENA-799
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki
>Reporter: Bruno P. Kinoshita
>Priority: Trivial
>  Labels: documentation, javadoc
>
> Added some Javadoc comments that may be useful for newcomers. I had to debug 
> a couple of times the work flow from when a SPARQL query comes via Fuseki, 
> and noticed the lack of comments in some methods.
> The code has been submitted as pull request to https://github.com/apache/jena 
> and I've added a comment in the pull request mentioning this issue ID. 
> Thanks!
> Bruno



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-800) Query response time severily regressed when upgraded Jena TDB to 2.11.2 from 0.9.4

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14176125#comment-14176125
 ] 

Bruno P. Kinoshita commented on JENA-800:
-

Hey Bala, while you are on it, do you think you could use some publicly 
available data set, or maybe share this last sample data you mentioned too? 
Others could use it to help you identify and maybe fix and write unit tests for 
the issue.

Thanks
Bruno

> Query response time severily regressed when upgraded Jena TDB to 2.11.2 from 
> 0.9.4
> --
>
> Key: JENA-800
> URL: https://issues.apache.org/jira/browse/JENA-800
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ, TDB
>Affects Versions: Jena 2.11.2
>Reporter: Bala Kolla
> Attachments: QueryExecutionLog_Jena_Ver_0_9_4.txt, 
> QueryExecutionLog_Jena_Ver_2_11_2.txt
>
>
> Many queries, that used to take few milliseconds in 0.9.4, are now taking 
> minutes.
> Here is one of the query that's taking few minutes instead of few 
> milliseconds. I will capture the algebra before and after and update this 
> issue once I have that data.
> PREFIX dcterms: 
> PREFIX rdf: 
> PREFIX rrmNav: 
> PREFIX jfs: 
> PREFIX rm: 
> SELECT ?url ?created ?creator ?modified ?modifier ?title ?description ?scope 
> ?etag
> WHERE
> { GRAPH ?g
> { ?url rdf:type rm:View .
> ?url jfs:resourceContext 
> { ?url dcterms:creator  .
> ?url rrmNav:scope "private"
> }
> UNION
> { ?url rrmNav:scope "public" }
> ?url dcterms:created ?created .
> ?url dcterms:creator ?creator .
> ?url dcterms:modified ?modified .
> ?url dcterms:title ?title .
> ?url dcterms:description ?description .
> ?url rrmNav:scope ?scope .
> ?url jfs:etag ?etag
> OPTIONAL
> { ?url dcterms:modifier ?modifier }
> }
> }
> ORDER BY DESC(?modified) DESC(?url)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-138) Broken links in the RDF tutorial: http://incubator.apache.org/jena/tutorials/index.html

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14176492#comment-14176492
 ] 

Bruno P. Kinoshita commented on JENA-138:
-

Hello, 

This issue is quite old, and I had a look at the RDF core API tutorial [1] but 
couldn't find the same broken links. 

I think the issue can be closed as Not Reproducible, unless Paolo can chime in 
and point if there are still broken links somewhere else.

Thoughts?

[1] http://jena.apache.org/tutorials/rdf_api.html

> Broken links in the RDF tutorial: 
> http://incubator.apache.org/jena/tutorials/index.html
> ---
>
> Key: JENA-138
> URL: https://issues.apache.org/jira/browse/JENA-138
> Project: Apache Jena
>  Issue Type: Task
>  Components: Web site
>Reporter: Paolo Castagna
>Priority: Trivial
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Links to the sources of the examples in the RDF tutorial 
> (http://incubator.apache.org/jena/tutorials/index.html) are broken, for 
> example:
> There is a link pointing to: 
> http://incubator.apache.org/src-examples/jena/examples/rdf/Tutorial01.java
> Links to glossary terms are not working too:
> http://incubator.apache.org/jena/tutorials/index.html#glos-blank%20node



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JENA-829) [PATCH] Fix link name for Apache git repositories

[Bruno P. Kinoshita (JIRA)]

Bruno P. Kinoshita created JENA-829:
---

 Summary: [PATCH] Fix link name for Apache git repositories
 Key: JENA-829
 URL: https://issues.apache.org/jira/browse/JENA-829
 Project: Apache Jena
  Issue Type: Documentation
  Components: Web site
Reporter: Bruno P. Kinoshita
Priority: Trivial


Hi, 

The link name for Apache git repositories in the live web site is broken and 
its text is wrong. In the staging web site, the link value is fixed, but the 
text continues incorrectly.

I had a look at the code from SVN trunk, and looks like the code needs to be 
updated. Here's a trivial patch that fixes this issue.

Hope that helps
Bruno



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-829) [PATCH] Fix link name for Apache git repositories

[Bruno P. Kinoshita (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated JENA-829:

Attachment: JENA-829.patch

> [PATCH] Fix link name for Apache git repositories
> -
>
> Key: JENA-829
> URL: https://issues.apache.org/jira/browse/JENA-829
> Project: Apache Jena
>  Issue Type: Documentation
>  Components: Web site
>Reporter: Bruno P. Kinoshita
>Priority: Trivial
>  Labels: documentation, patch, trivial, website
> Attachments: JENA-829.patch
>
>
> Hi, 
> The link name for Apache git repositories in the live web site is broken and 
> its text is wrong. In the staging web site, the link value is fixed, but the 
> text continues incorrectly.
> I had a look at the code from SVN trunk, and looks like the code needs to be 
> updated. Here's a trivial patch that fixes this issue.
> Hope that helps
> Bruno



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-829) [PATCH] Fix link text for Apache git repositories

[Bruno P. Kinoshita (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated JENA-829:

Summary: [PATCH] Fix link text for Apache git repositories  (was: [PATCH] 
Fix link name for Apache git repositories)

> [PATCH] Fix link text for Apache git repositories
> -
>
> Key: JENA-829
> URL: https://issues.apache.org/jira/browse/JENA-829
> Project: Apache Jena
>  Issue Type: Documentation
>  Components: Web site
>Reporter: Bruno P. Kinoshita
>Priority: Trivial
>  Labels: documentation, patch, trivial, website
> Attachments: JENA-829.patch
>
>
> Hi, 
> The link name for Apache git repositories in the live web site is broken and 
> its text is wrong. In the staging web site, the link value is fixed, but the 
> text continues incorrectly.
> I had a look at the code from SVN trunk, and looks like the code needs to be 
> updated. Here's a trivial patch that fixes this issue.
> Hope that helps
> Bruno



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-43) documentation errors on "the Assembler howto"

[Bruno P. Kinoshita (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated JENA-43:
---
Attachment: JENA-43.patch

Hello, 

Ressurrecting an old issue.

Firstly, the page is now at 
http://jena.apache.org/documentation/assembler/assembler-howto.html. The 
attached patch fixes HTML section links.

> 1) missing section: loading-assembler-classes referenced by link in "other 
> Assembler directives"
> I'd say this is trivial but I'd really like to read this section if it 
> exists...

This section is in the companion page. I tried to link it in the patch 
attached, but am not sure if I used the right syntax, and I couldn't find 
instructions to build the site locally.

> 2) In "overview section" eg:model appears twice. I think it should be 
> eg:opening-example instead.
> I'd say it is trivial but for someone new like me this was making reading 
> that section pretty confusing.

Looks like someone else already took care of that after the migration from 
sourceforge.

> 3) In section "content" this appears when shown as "N3"

I can't really say whether this one is still broken or not. But IIUC, the 
example is not wrong, but maybe could be enhanced in the future?

> 4) link to http://jena.sourceforge.net/vocabularies/assembler.n3 is 404

Not used anymore.

> documentation errors on "the Assembler howto"
> -
>
> Key: JENA-43
> URL: https://issues.apache.org/jira/browse/JENA-43
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Web site
>Reporter: Tim Harsch
>Assignee: christopher james dollin
> Attachments: JENA-43.patch
>
>
> I found these errors on the page:
> http://jena.sourceforge.net/assembler/assembler-howto.html
> 1) missing section:  loading-assembler-classes referenced by link in "other 
> Assembler directives"
>I'd say this is trivial but I'd really like to read this section if it 
> exists...
> 2) In "overview section" eg:model appears twice.  I think it should be 
> eg:opening-example instead.
>   I'd say it is trivial but for someone new like me this was making reading 
> that section pretty confusing.
> 3)  In section "content"  this appears when shown as "N3"
> ja:HasFileManager a rdfs:Class 
> ; rdfs:subClassOf ja:Object
> .
> ja:fileManager a rdf:Property 
> ; rdfs:domain ja:HasFileManager
> ; rdfs:range ja:FileManager
> but when shown as condensed it is:
> class ja:HasFileManager subClassOf ja:Object 
> domainOf ja:fileManager withRange ja:FileManager
> they are not semantically the same.  OK this may be trivial, but the 
> condensed form is a little confusing.
> 4) link to http://jena.sourceforge.net/vocabularies/assembler.n3 is 404



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JENA-830) [PATCH] Fix section links in the tdb commands page

[Bruno P. Kinoshita (JIRA)]

Bruno P. Kinoshita created JENA-830:
---

 Summary: [PATCH] Fix section links in the tdb commands page
 Key: JENA-830
 URL: https://issues.apache.org/jira/browse/JENA-830
 Project: Apache Jena
  Issue Type: Documentation
  Components: Web site
Reporter: Bruno P. Kinoshita
Priority: Trivial


Hello, while reading some pages for JENA-456, I found a few more issues - 
interestingly, they are not exactly 404 errors, but just wrong section ID's. 

The attached patch contains the fix for these links.

Hope that helps,
Bruno



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-830) [PATCH] Fix section links in the tdb commands page

[Bruno P. Kinoshita (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated JENA-830:

Attachment: JENA-830.patch

> [PATCH] Fix section links in the tdb commands page
> --
>
> Key: JENA-830
> URL: https://issues.apache.org/jira/browse/JENA-830
> Project: Apache Jena
>  Issue Type: Documentation
>  Components: Web site
>Reporter: Bruno P. Kinoshita
>Priority: Trivial
>  Labels: documentation, trivial, website
> Attachments: JENA-830.patch
>
>
> Hello, while reading some pages for JENA-456, I found a few more issues - 
> interestingly, they are not exactly 404 errors, but just wrong section ID's. 
> The attached patch contains the fix for these links.
> Hope that helps,
> Bruno



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JENA-831) [PATCH] Fix section link, typos and duplicated block

[Bruno P. Kinoshita (JIRA)]

Bruno P. Kinoshita created JENA-831:
---

 Summary: [PATCH] Fix section link, typos and duplicated block
 Key: JENA-831
 URL: https://issues.apache.org/jira/browse/JENA-831
 Project: Apache Jena
  Issue Type: Documentation
  Components: Web site
Reporter: Bruno P. Kinoshita
Priority: Minor


Hello, 

The attached patch fixes a section link, some typos and a duplicated text block 
in the jena-text module documentation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-831) [PATCH] Fix section link, typos and duplicated block

[Bruno P. Kinoshita (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated JENA-831:

Attachment: JENA-831.patch

> [PATCH] Fix section link, typos and duplicated block
> 
>
> Key: JENA-831
> URL: https://issues.apache.org/jira/browse/JENA-831
> Project: Apache Jena
>  Issue Type: Documentation
>  Components: Web site
>Reporter: Bruno P. Kinoshita
>Priority: Minor
>  Labels: patch, typo, website
> Attachments: JENA-831.patch
>
>
> Hello, 
> The attached patch fixes a section link, some typos and a duplicated text 
> block in the jena-text module documentation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-788) Check git and github pull request integration

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253889#comment-14253889
 ] 

Bruno P. Kinoshita commented on JENA-788:
-

The integration seems to be working -> 
http://mail-archives.apache.org/mod_mbox/jena-dev/201411.mbox/browser

Probably some temporary issue with the mail daemon. Not sure if it creates 
JIRA's, in Apache Commons it only send an e-mail and JIRA issues are manually 
opened. 

Maybe this issue can be closed?

> Check git and github pull request integration
> -
>
> Key: JENA-788
> URL: https://issues.apache.org/jira/browse/JENA-788
> Project: Apache Jena
>  Issue Type: Task
>Reporter: Andy Seaborne
>
> There was a pull request recently but it did npt cause a JIRA to be created 
> nor a email to go to the dev@ list.
> https://github.com/apache/jena/pull/6



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-563) Statement from Default Model does not throw exception when creating Bag

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253955#comment-14253955
 ] 

Bruno P. Kinoshita commented on JENA-563:
-

StatementImpl#getBag uses an RDFNode to cast the object to Bag (IIUC it 
actually wraps the Resource within a Bag object if the object is not a Bag).

Several methods in Statement state that an exception will be thrown if the 
underlying object is not of the right type. I think we can either close this 
issue as Not An Issue, or remove the statement from all Javadocs in Statement. 
I'm okay with any of these options.

> Statement from Default Model does not throw exception when creating Bag
> ---
>
> Key: JENA-563
> URL: https://issues.apache.org/jira/browse/JENA-563
> Project: Apache Jena
>  Issue Type: Bug
>Reporter: Claude Warren
> Attachments: dummy.java
>
>
> The documentation for Statement.getBag() states:
> "An exception will be thrown if the object is not a Resource."
> However in the case of the default model creating an Bag on a Literal 
> succeeds.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-562) Statement from Default Model does not throw exception when creating Seq

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253956#comment-14253956
 ] 

Bruno P. Kinoshita commented on JENA-562:
-

Similar to JENA-563. 

> Statement from Default Model does not throw exception when creating Seq
> ---
>
> Key: JENA-562
> URL: https://issues.apache.org/jira/browse/JENA-562
> Project: Apache Jena
>  Issue Type: Bug
>Reporter: Claude Warren
> Attachments: dummy.java
>
>
> The documentation for Statement.getSeq() states:
> "An exception will be thrown if the object is not a Resource."
> However in the case of the default model creating an Seq on a Literal 
> succeeds.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-561) Statement from Default Model does not throw exception when creating Alt

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253960#comment-14253960
 ] 

Bruno P. Kinoshita commented on JENA-561:
-

Similar to JENA-563. 

> Statement from Default Model does not throw exception when creating Alt
> ---
>
> Key: JENA-561
> URL: https://issues.apache.org/jira/browse/JENA-561
> Project: Apache Jena
>  Issue Type: Bug
>Reporter: Claude Warren
> Attachments: dummy.java
>
>
> The documentation for Statement.getAlt() states:
> "An exception will be thrown if the object is not a Resource."
> However in the case of the default model creating an Alt on a Literal 
> succeeds.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-354) running eyeball tests fails

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253965#comment-14253965
 ] 

Bruno P. Kinoshita commented on JENA-354:
-

Successfully built eyeball after downloading it from SourceForge archive 
folder. Built with `mvn clean test`. I think this issue can be closed.

> running eyeball tests fails
> ---
>
> Key: JENA-354
> URL: https://issues.apache.org/jira/browse/JENA-354
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Eyeball
>Affects Versions: Jena 2.10.0
>Reporter: Jos
>
> Building eyeball and running the tests fails.
> Eyeball was obtained with 
>  svn clone https://svn.apache.org/repos/asf/jena/Scratch/Eyeball/trunk/
> then these binary jars were put in the lib/ directory:
>  jena-core-2.7.4.jar
>  jena-iri-0.9.4.jar
>  jena-arq-2.9.4.jar
>  jena-core-2.7.4-tests.jar
> eyeball.jar was created by running 'ant'
> Then an attempt was made to run the tests with 'ant test' which resulted in:
>   BUILD FAILED
> /tmp/trunk/build.xml:146: /tmp/trunk/src-test does not exist.
> Creating the missing resulted in the command 'ant test' ending with
>  BUILD SUCCESSFUL
> but no tests were run.
> So src-test and it's content is missing from the repository.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-285) rdfcat does not respect -n flag

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253988#comment-14253988
 ] 

Bruno P. Kinoshita commented on JENA-285:
-

I think this issue has been fixed in the code already and can be closed. I used 
the following example from http://www.w3.org/TR/n-triples/

{noformat}
  
 . # comments here
# or on a line by themselves
_:subject1  "object1" .
_:subject2  "object2" .
{noformat}

And running the latest version of rdfcat as

{noformat}rdfcat -n /home/kinow/Desktop/1.n3 -out N3{noformat}

produces the following output

{noformat}
[]
  "object1" .

[]
  "object2" .


  
   .
{noformat}

> rdfcat does not respect -n flag
> ---
>
> Key: JENA-285
> URL: https://issues.apache.org/jira/browse/JENA-285
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Cmd line tools
>Affects Versions: Jena 2.7.2
>Reporter: Ian Dickinson
>
> -n flag (n-triples input syntax) is overridden by the file-extension guessing 
> heuristics in the FileManager



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-832) [PATCH] Remove the JIRA popular issues mention from the pages

[Bruno P. Kinoshita (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated JENA-832:

Attachment: JENA-832.patch

> [PATCH] Remove the JIRA popular issues mention from the pages
> -
>
> Key: JENA-832
> URL: https://issues.apache.org/jira/browse/JENA-832
> Project: Apache Jena
>  Issue Type: Documentation
>  Components: Web site
>Reporter: Bruno P. Kinoshita
>Priority: Trivial
>  Labels: jira, website
> Attachments: JENA-832.patch
>
>
> Hi, 
> The popular issues link is not working in Getting Involved and Roadmap pages. 
> The attached patch removes both mentions. 
> Looks like it was available for JIRA 6.1 users, but was removed in 6.2 
> (https://confluence.atlassian.com/display/JIRA/JIRA+6.2+Upgrade+Notes#JIRA6.2UpgradeNotes-LabelsandPopularIssuestabsremovedfromProjectOverview).
>  We use the 6.3 if I'm not mistaken at ASF.
> Hope that helps
> Bruno



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JENA-832) [PATCH] Remove the JIRA popular issues mention from the pages

[Bruno P. Kinoshita (JIRA)]

Bruno P. Kinoshita created JENA-832:
---

 Summary: [PATCH] Remove the JIRA popular issues mention from the 
pages
 Key: JENA-832
 URL: https://issues.apache.org/jira/browse/JENA-832
 Project: Apache Jena
  Issue Type: Documentation
  Components: Web site
Reporter: Bruno P. Kinoshita
Priority: Trivial
 Attachments: JENA-832.patch

Hi, 

The popular issues link is not working in Getting Involved and Roadmap pages. 
The attached patch removes both mentions. 

Looks like it was available for JIRA 6.1 users, but was removed in 6.2 
(https://confluence.atlassian.com/display/JIRA/JIRA+6.2+Upgrade+Notes#JIRA6.2UpgradeNotes-LabelsandPopularIssuestabsremovedfromProjectOverview).
 We use the 6.3 if I'm not mistaken at ASF.

Hope that helps
Bruno



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-833) [PATCH] Javadocs for ConNeg

[Bruno P. Kinoshita (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated JENA-833:

Attachment: JENA-833.patch

> [PATCH] Javadocs for ConNeg
> ---
>
> Key: JENA-833
> URL: https://issues.apache.org/jira/browse/JENA-833
> Project: Apache Jena
>  Issue Type: Documentation
>  Components: Documentation
>Reporter: Bruno P. Kinoshita
>Priority: Trivial
>  Labels: documentaion, javadoc, patch
> Attachments: JENA-833.patch
>
>
> Attached patch with proposal Javadocs for ConNeg, based on the RFC, httpd and 
> Wiki page on Content Negotiation for HTTP.
> I noticed ConNeg has several "match" methods, and calls other classes with 
> similar named methods. I'll take a look later and will write more tests for 
> ConNeg (it has poor coverage) and other classes in a separate issue.
> Hope that helps,
> Bruno



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JENA-833) [PATCH] Javadocs for ConNeg

[Bruno P. Kinoshita (JIRA)]

Bruno P. Kinoshita created JENA-833:
---

 Summary: [PATCH] Javadocs for ConNeg
 Key: JENA-833
 URL: https://issues.apache.org/jira/browse/JENA-833
 Project: Apache Jena
  Issue Type: Documentation
  Components: Documentation
Reporter: Bruno P. Kinoshita
Priority: Trivial
 Attachments: JENA-833.patch

Attached patch with proposal Javadocs for ConNeg, based on the RFC, httpd and 
Wiki page on Content Negotiation for HTTP.

I noticed ConNeg has several "match" methods, and calls other classes with 
similar named methods. I'll take a look later and will write more tests for 
ConNeg (it has poor coverage) and other classes in a separate issue.

Hope that helps,
Bruno



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14255033#comment-14255033
 ] 

Bruno P. Kinoshita commented on JENA-632:
-

Hi, 

I've been trying to write a patch for this, but before having a definitive 
patch to submit I'll need to write a bunch of things :)

At the moment what I managed to do was to understand how the SPARQL and ARQ 
grammars are generated (with JavaCC) and I've updated them (in master.jj, which 
creates sparql_11.jj, arq.jj and other files via grammar executable).

You can check my work-in-progress grammar here 
https://gist.github.com/kinow/875851f7379abfcb4f13

I haven't messed up with compiler generators and grammars in a while, last time 
was in 2010 but I used Antlr. So there are probably parts that can be enhanced 
(like [this 
part|https://gist.github.com/kinow/875851f7379abfcb4f13#file-gistfile1-java-L350]
 where I couldn't make JavaCC recognize a  token).

Even though the grammar seems to be working, and I'm collecting the "variable": 
?variable in a java.util.Map in the Query object, I still have to update SPARQL 
and Fuseki to return JSON. 

> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Priority: Minor
>  Labels: gsoc, java, javacc
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL) 
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user 
> community, basic understanding of HTTP and content negotiation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JENA-632) Generate JSON from SPARQL directly.

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14255033#comment-14255033
 ] 

Bruno P. Kinoshita edited comment on JENA-632 at 12/21/14 3:51 AM:
---

Hi, 

I've been trying to write a patch for this, but before having a definitive 
patch to submit I'll need to learn a bunch of things :)

At the moment what I managed to do was to understand how the SPARQL and ARQ 
grammars are generated (with JavaCC) and I've updated them (master.jj, which 
creates sparql_11.jj, arq.jj and other files via the grammar executable).

You can check my work-in-progress updated grammar here 
https://gist.github.com/kinow/875851f7379abfcb4f13

I haven't messed up with compiler generators and grammars in a while, last time 
was in 2010 but I used Antlr. So there are probably parts that can be enhanced 
(like [this 
part|https://gist.github.com/kinow/875851f7379abfcb4f13#file-gistfile1-java-L350]
 where I couldn't make JavaCC recognize a  token).

Even though the grammar seems to be working, and I'm collecting the "variable": 
?variable in a java.util.Map in the Query object, I still have to update SPARQL 
and Fuseki to return JSON. 

BTW: I'm implementing what Andy suggested in the mailing list, a {{SELECT 
JSON}} statement, rather than {{CONSTRUCT JSON}}.


was (Author: kinow):
Hi, 

I've been trying to write a patch for this, but before having a definitive 
patch to submit I'll need to write a bunch of things :)

At the moment what I managed to do was to understand how the SPARQL and ARQ 
grammars are generated (with JavaCC) and I've updated them (in master.jj, which 
creates sparql_11.jj, arq.jj and other files via grammar executable).

You can check my work-in-progress grammar here 
https://gist.github.com/kinow/875851f7379abfcb4f13

I haven't messed up with compiler generators and grammars in a while, last time 
was in 2010 but I used Antlr. So there are probably parts that can be enhanced 
(like [this 
part|https://gist.github.com/kinow/875851f7379abfcb4f13#file-gistfile1-java-L350]
 where I couldn't make JavaCC recognize a  token).

Even though the grammar seems to be working, and I'm collecting the "variable": 
?variable in a java.util.Map in the Query object, I still have to update SPARQL 
and Fuseki to return JSON. 

> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Priority: Minor
>  Labels: gsoc, java, javacc
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL) 
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user 
> community, basic understanding of HTTP and content negotiation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-64) Failed read of imported ontology leaves a memory in the ModelMaker

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14257791#comment-14257791
 ] 

Bruno P. Kinoshita commented on JENA-64:


Hi Ian, spent some time this afternoon trying to reproduce the issue with no 
success. Could you share some snippet of code to reproduce it? Doesn't sound so 
hard to propose a patch with a possible fix, but maybe it is harder to 
reproduce?

Thanks!
Bruno

> Failed read of imported ontology leaves a memory in the ModelMaker
> --
>
> Key: JENA-64
> URL: https://issues.apache.org/jira/browse/JENA-64
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Ontology API
>Reporter: Ian Dickinson
>Assignee: Ian Dickinson
>
> If an OntModel tries to create sub-models for imports, and the attempt to 
> read an import fails, an empty model is left associated with the source URL 
> in the memory retained by SimpleGraphMaker. Subsequent attempts to read the 
> import URI, e.g. with a FileManager redirect in place to avoid the network 
> issue, return only the empty model from the failed read and do not read the 
> updated source.
> Failed model reads should not leave a memory in the graph maker. Possibly, 
> graph maker should not have a memory at all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-612) Fuseki does not log an error when failing to open a TDB dataset

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14258379#comment-14258379
 ] 

Bruno P. Kinoshita commented on JENA-612:
-

Successfully reproduced this issue on Ubuntu 14.04, JDK 1.7. In my case I start 
Fuseki with the user fuseki, pointing to /var/lib/jena/DB. Stopped the service, 
chown'd the directory to root and chmod'd it to 0755. 

Started Fuseki, noticed the success startup message, but a {{service fuseki 
status}} right after that gives me that fuseki is not running. Nothing in the 
logs too. 

In the pull request https://github.com/apache/jena/pull/13, instead of starting 
the {{java}} executable in the init script, it utilizes {{--startas /bin/bash 
-- -c "exec $JAVA $RUN_ARGS\[*\] > $FUSEKI_LOGS_STDERROUT 2>&1"}}

After applying it in my local env, this is what I get:

{noformat}
root@chuva:/opt/fuseki# service fuseki start
Starting Fuseki: /usr/bin/java -Xmx1200M -jar /opt/fuseki/fuseki-server.jar 
--loc=/var/lib/jena/DB --port=3030 --update /ds
STARTED Fuseki Wed Dec 24 14:37:12 BRST 2014
PID=13707
{noformat}

And a {{cat /opt/fuseki/stderrout.log}}

{noformat}
com.hp.hpl.jena.tdb.base.file.FileException: Failed to open: 
/var/lib/jena/DB/node2id.idn (mode=rw)
at 
com.hp.hpl.jena.tdb.base.file.ChannelManager.open$(ChannelManager.java:82)
at 
com.hp.hpl.jena.tdb.base.file.ChannelManager.openref$(ChannelManager.java:56)
at 
com.hp.hpl.jena.tdb.base.file.ChannelManager.acquire(ChannelManager.java:45)
at com.hp.hpl.jena.tdb.base.file.FileBase.(FileBase.java:61)
at com.hp.hpl.jena.tdb.base.file.FileBase.(FileBase.java:50)
at com.hp.hpl.jena.tdb.base.file.FileBase.create(FileBase.java:45)
at 
com.hp.hpl.jena.tdb.base.file.BlockAccessBase.(BlockAccessBase.java:46)
at 
com.hp.hpl.jena.tdb.base.file.BlockAccessMapped.(BlockAccessMapped.java:63)
at 
com.hp.hpl.jena.tdb.base.block.BlockMgrFactory.createMMapFile(BlockMgrFactory.java:90)
at 
com.hp.hpl.jena.tdb.base.block.BlockMgrFactory.createFile(BlockMgrFactory.java:80)
at 
com.hp.hpl.jena.tdb.base.block.BlockMgrFactory.create(BlockMgrFactory.java:58)
at 
com.hp.hpl.jena.tdb.setup.Builder$BlockMgrBuilderStd.buildBlockMgr(Builder.java:196)
at 
com.hp.hpl.jena.tdb.setup.Builder$RangeIndexBuilderStd.createBPTree(Builder.java:165)
at 
com.hp.hpl.jena.tdb.setup.Builder$RangeIndexBuilderStd.buildRangeIndex(Builder.java:134)
at 
com.hp.hpl.jena.tdb.setup.Builder$IndexBuilderStd.buildIndex(Builder.java:112)
at 
com.hp.hpl.jena.tdb.setup.Builder$NodeTableBuilderStd.buildNodeTable(Builder.java:85)
at 
com.hp.hpl.jena.tdb.setup.DatasetBuilderStd$NodeTableBuilderRecorder.buildNodeTable(DatasetBuilderStd.java:369)
at 
com.hp.hpl.jena.tdb.setup.DatasetBuilderStd.makeNodeTable(DatasetBuilderStd.java:280)
at 
com.hp.hpl.jena.tdb.setup.DatasetBuilderStd._build(DatasetBuilderStd.java:141)
at 
com.hp.hpl.jena.tdb.setup.DatasetBuilderStd.build(DatasetBuilderStd.java:131)
at 
com.hp.hpl.jena.tdb.setup.DatasetBuilderStd.build(DatasetBuilderStd.java:66)
at com.hp.hpl.jena.tdb.StoreConnection.make(StoreConnection.java:216)
at 
com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction.(DatasetGraphTransaction.java:75)
at com.hp.hpl.jena.tdb.sys.TDBMaker._create(TDBMaker.java:57)
at 
com.hp.hpl.jena.tdb.sys.TDBMaker.createDatasetGraphTransaction(TDBMaker.java:45)
at 
com.hp.hpl.jena.tdb.TDBFactory._createDatasetGraph(TDBFactory.java:104)
at com.hp.hpl.jena.tdb.TDBFactory.createDatasetGraph(TDBFactory.java:73)
at com.hp.hpl.jena.tdb.TDBFactory.createDatasetGraph(TDBFactory.java:69)
at 
org.apache.jena.fuseki.FusekiCmd.processModulesAndArgs(FusekiCmd.java:297)
at arq.cmdline.CmdArgModule.process(CmdArgModule.java:51)
at arq.cmdline.CmdMain.mainMethod(CmdMain.java:101)
at arq.cmdline.CmdMain.mainRun(CmdMain.java:63)
at arq.cmdline.CmdMain.mainRun(CmdMain.java:50)
at org.apache.jena.fuseki.FusekiCmd.main(FusekiCmd.java:167)
Caused by: java.io.FileNotFoundException: /var/lib/jena/DB/node2id.idn 
(Permission denied)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.(RandomAccessFile.java:241)
at java.io.RandomAccessFile.(RandomAccessFile.java:122)
at 
com.hp.hpl.jena.tdb.base.file.ChannelManager.open$(ChannelManager.java:79)
... 33 more
{noformat}

Fixing the issue: 

{noformat}
root@chuva:/opt/fuseki# chown fuseki: /var/lib/jena/DB -R
root@chuva:/opt/fuseki# service fuseki start
Starting Fuseki: /usr/bin/java -Xmx1200M -jar /opt/fuseki/fuseki-server.jar 
--loc=/var/lib/jena/DB --port=3030 --update /ds
STARTED Fuseki Wed Dec 24 14:41:55 BRST 2014
PID=14018
root@chuva:/opt/fuseki# service fuseki status
Fuseki is running wi

[jira] [Commented] (JENA-557) SimpleEventManger no longer needs Graph object

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14258383#comment-14258383
 ] 

Bruno P. Kinoshita commented on JENA-557:
-

I think this issue can be closed as Won't fix or Not an issue. 

Even though the Graph object never gets read in SimpleEventManager, it was 
probably done this way by design. 

The {{graph}} member object is marked as {{protected}} and can be accessed in 
child classes, as it happens in {{EventManagerSDB}}.

> SimpleEventManger no longer needs Graph object
> --
>
> Key: JENA-557
> URL: https://issues.apache.org/jira/browse/JENA-557
> Project: Apache Jena
>  Issue Type: Bug
>Reporter: Claude Warren
>Priority: Minor
>
> The Graph object passed in the SimpleEventManger constructor is not used and 
> is no longer used in any code that I can find.
> Suggest deprecating the current constructor and replacing with a new no-arg 
> constructor.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14258386#comment-14258386
 ] 

Bruno P. Kinoshita commented on JENA-632:
-

Thanks for your feedback on this Andy! I was already going to start hacking the 
SPARQL code :-)

I'm +1 for making it {{JSON}}. It will make the grammar simpler, and I think it 
will be clearer for users that this is a new statement and has a different 
syntax. 

I'll play with the grammar again during holidays and will post a new version 
soon. 

Thanks again,
Bruno

> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Priority: Minor
>  Labels: gsoc, java, javacc
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL) 
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user 
> community, basic understanding of HTTP and content negotiation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-355) eyeball throws exception on simple file

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259248#comment-14259248
 ] 

Bruno P. Kinoshita commented on JENA-355:
-

This issue has probably been fixed already. Just tried to reproduce Jos' steps.

{noformat}
kinow@chuva:/tmp/eyeball/target$ echo '' > a.xml
kinow@chuva:/tmp/eyeball/target$ java -jar eyeball-2.4.0-SNAPSHOT-exec.jar 
-check a.xml
 WARN [main] (RDFDefaultErrorHandler.java:49) - file:a.xml(line 1 column 5): 
{W104} Unqualified typed nodes are not allowed. Type treated as a relative URI.
 WARN [main] (RDFDefaultErrorHandler.java:49) - file:a.xml(line 1 column 5): 
{W136} Relative URIs are not permitted in RDF: specifically 

On statement:  _:b1001 rdf:type a
class not declared in any schema: a

On statement:  _:b1001 rdf:type a
eye:badURI: "a"
for reason: URI has no scheme
kinow@chuva:/tmp/eyeball/target$ 
{noformat}

I think this issue can be closed as Not reproducible, or similar status. Cheers.

> eyeball throws exception on simple file
> ---
>
> Key: JENA-355
> URL: https://issues.apache.org/jira/browse/JENA-355
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Eyeball
>Affects Versions: Jena 2.10.0
>Reporter: Jos
>
> Running
> java -cp 
> lib/slf4j-api-1.7.2.jar:lib/eyeball.jar:lib/jena-core-2.7.4.jar:lib/xerces-j2.jar:lib/batik-ext.jar:lib/jena-iri-0.9.4.jar
>  jena.eyeball -check a.xml
> with contents of a.xml: "" gives this exception:
> Caused by: java.lang.NullPointerException
> at 
> com.hp.hpl.jena.rdf.arp.impl.XMLHandler.endElement(XMLHandler.java:135)
> at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown 
> Source)
> at org.apache.xerces.impl.XMLNamespaceBinder.handleEndElement(Unknown 
> Source)
> at org.apache.xerces.impl.XMLNamespaceBinder.endElement(Unknown 
> Source)
> at 
> org.apache.xerces.impl.dtd.XMLDTDValidator.endNamespaceScope(Unknown Source)
> at 
> org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement(Unknown Source)
> at org.apache.xerces.impl.dtd.XMLDTDValidator.endElement(Unknown 
> Source)
> at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown 
> Source)
> at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
>  Source)
> at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
> Source)
> at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
> at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at 
> com.hp.hpl.jena.rdf.arp.impl.RDFXMLParser.parse(RDFXMLParser.java:155)
> at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:173)
> at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:160)
> at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:232)
> at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:99)
> at com.hp.hpl.jena.rdf.model.impl.ModelCom.read(ModelCom.java:241)
> at 
> com.hp.hpl.jena.util.FileManager.readModelWorker(FileManager.java:375)
> at 
> com.hp.hpl.jena.util.FileManager.loadModelWorker(FileManager.java:306)
> at com.hp.hpl.jena.util.FileManager.loadModel(FileManager.java:258)
> at 
> com.hp.hpl.jena.eyeball.inspectors.VocabularyInspector.(VocabularyInspector.java:50)
> at 
> com.hp.hpl.jena.eyeball.inspectors.VocabularyInspector.(VocabularyInspector.java:37)
> ... 42 more



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-280) OntTools.nameHierarchyRoots gives wrong answer when reasoner attached

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259251#comment-14259251
 ] 

Bruno P. Kinoshita commented on JENA-280:
-

For the record, here is the code in that gist.

XML:

{noformat}
http://www.w3.org/1999/02/22-rdf-syntax-ns#";
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#";
xmlns:owl="http://www.w3.org/2002/07/owl#"; >
http://dbpedia.org/class/yago/Album106591815"/>
http://dbpedia.org/class/yago/HostCitiesOfTheCommonwealthGames"/>
http://dbpedia.org/property/after";>  



http://dbpedia.org/class/yago/Album106591815"/>





{noformat}

Full code:

{noformat}
package com.tupilabs.jena;

import java.io.StringReader;
import java.util.Iterator;

import com.hp.hpl.jena.ontology.OntClass;
import com.hp.hpl.jena.ontology.OntModel;
import com.hp.hpl.jena.ontology.OntModelSpec;
import com.hp.hpl.jena.ontology.OntTools;
import com.hp.hpl.jena.rdf.model.ModelFactory;
import com.hp.hpl.jena.util.iterator.ExtendedIterator;

public class Tests102 {

public static final String SOURCE = "\n"
+ "http://www.w3.org/1999/02/22-rdf-syntax-ns#\"\n";
+ "
xmlns:rdfs=\"http://www.w3.org/2000/01/rdf-schema#\"\n";
+ "xmlns:owl=\"http://www.w3.org/2002/07/owl#\"; >\n"
+ "http://dbpedia.org/class/yago/Album106591815\"/>\n"
+ "http://dbpedia.org/class/yago/HostCitiesOfTheCommonwealthGames\"/>\n"
+ "http://dbpedia.org/property/after\";>  \n"
+ "\n"
+ "\n"
+ "\n"
+ "http://dbpedia.org/class/yago/Album106591815\"/>\n"
+ "\n" + "\n" + 
"\n"
+ "\n" + "";

public static void main(String[] args) {
System.out.println(SOURCE);
OntModel m = ModelFactory

.createOntologyModel(OntModelSpec.OWL_MEM_MICRO_RULE_INF);
m.read(new StringReader(SOURCE), "RDF/XML");

for (ExtendedIterator i = 
m.listHierarchyRootClasses(); i
.hasNext();) {
System.out.println("LHRC -> " + i.next());
}

OntModel base = 
ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM,
m.getBaseModel());
for (Iterator i = OntTools.namedHierarchyRoots(base)
.iterator(); i.hasNext();) {
System.out.println("NHR -> " + i.next());
}
}

}
{noformat}

Looks like the behavior persists with the code in the trunk.

{noformat}
LHRC -> c38a4ee:14a8919b767:-7ffc
LHRC -> http://dbpedia.org/class/yago/HostCitiesOfTheCommonwealthGames
NHR -> http://dbpedia.org/class/yago/HostCitiesOfTheCommonwealthGames
NHR -> http://dbpedia.org/class/yago/Album106591815
{noformat}


> OntTools.nameHierarchyRoots gives wrong answer when reasoner attached
> -
>
> Key: JENA-280
> URL: https://issues.apache.org/jira/browse/JENA-280
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Ontology API
>Reporter: Ian Dickinson
>Assignee: Ian Dickinson
>
> See https://gist.github.com/3143188 for setup



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-557) SimpleEventManger no longer needs Graph object

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259539#comment-14259539
 ] 

Bruno P. Kinoshita commented on JENA-557:
-

Makes sense Andy, liked how it also reduced the coupling between the classes +1 
:)

> SimpleEventManger no longer needs Graph object
> --
>
> Key: JENA-557
> URL: https://issues.apache.org/jira/browse/JENA-557
> Project: Apache Jena
>  Issue Type: Bug
>Reporter: Claude Warren
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 2.12.2
>
>
> The Graph object passed in the SimpleEventManger constructor is not used and 
> is no longer used in any code that I can find.
> Suggest deprecating the current constructor and replacing with a new no-arg 
> constructor.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-456) Document "tdbquery --explain"

[Bruno P. Kinoshita (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated JENA-456:

Attachment: JENA-456.patch

First take on tdbquery --explain documentation. I've added it to the optimizer 
docs. First I created an empty page for it, but then noticed that most logging 
information is already present in the optimizer Wiki.

I used the books.ttl for testing and didn't include the query output, only the 
execution details and a simple dummy query. But maybe the explanation details 
of more complicated queries would be better? 

I also haven't covered why it is important to take a look at the algebra, 
query, etc, as I'm not very experienced with it :) so please feel free to send 
suggestions for improvements, no hard feelings.

> Document "tdbquery --explain"
> -
>
> Key: JENA-456
> URL: https://issues.apache.org/jira/browse/JENA-456
> Project: Apache Jena
>  Issue Type: Task
>  Components: Web site
>Reporter: Andy Seaborne
>Priority: Minor
> Attachments: JENA-456.patch
>
>
> Note on 
> https://jena.apache.org/documentation/tdb/optimizer.html
> and 
> https://jena.apache.org/documentation/tdb/commands.html#tdbquery



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-594) rdfcat silently ignores - as stdin if input type isn't specified

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259772#comment-14259772
 ] 

Bruno P. Kinoshita commented on JENA-594:
-

{{`jena.rdfcat`}} now will print the usage, since the user didn't provide any 
input (I couldn't find the usage, but later noticed that I can trigger it by 
using {{`jena.rdfcat usage`}}).

{{`jena.rdfcat -out N3 -x file:sample.rdf`}} works as expected.

> Using -, non RDF/XML content is silently ignored. Specifying -n gets it 
> treated correctly.

{noformat}
$ echo '  ' | rdfcat -
 WARN [main] (ErrorHandlerFactory.java:77) - [line: 1, col: 4 ] {W104} 
Unqualified typed nodes are not allowed. Type treated as a relative URI.
 WARN [main] (ErrorHandlerFactory.java:77) - [line: 1, col: 4 ] {W136} Relative 
URIs are not permitted in RDF: specifically 
 WARN [main] (ErrorHandlerFactory.java:77) - [line: 1, col: 8 ] {W104} 
Unqualified property elements are not allowed. Treated as a relative URI.
 WARN [main] (ErrorHandlerFactory.java:77) - [line: 1, col: 8 ] {W136} Relative 
URIs are not permitted in RDF: specifically 
 WARN [main] (ErrorHandlerFactory.java:77) - [line: 1, col: 12] {W104} 
Unqualified typed nodes are not allowed. Type treated as a relative URI.
 WARN [main] (ErrorHandlerFactory.java:77) - [line: 1, col: 12] {W136} Relative 
URIs are not permitted in RDF: specifically 
ERROR [main] (ErrorHandlerFactory.java:84) - [line: 2, col: 1 ] XML document 
structures must start and end within the same entity.
Exception in thread "main" org.apache.jena.riot.RiotException: [line: 2, col: 1 
] XML document structures must start and end within the same entity.
at 
org.apache.jena.riot.system.ErrorHandlerFactory$ErrorHandlerStd.fatal(ErrorHandlerFactory.java:136)
at 
org.apache.jena.riot.lang.LangRDFXML$ErrorHandlerBridge.fatalError(LangRDFXML.java:249)
at 
com.hp.hpl.jena.rdfxml.xmlinput.impl.ARPSaxErrorHandler.fatalError(ARPSaxErrorHandler.java:48)
at 
com.hp.hpl.jena.rdfxml.xmlinput.impl.XMLHandler.warning(XMLHandler.java:200)
at 
com.hp.hpl.jena.rdfxml.xmlinput.impl.XMLHandler.fatalError(XMLHandler.java:230)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.endEntity(Unknown Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl.endEntity(Unknown 
Source)
at org.apache.xerces.impl.XMLEntityManager.endEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.scanContent(Unknown Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanContent(Unknown 
Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
 Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at 
com.hp.hpl.jena.rdfxml.xmlinput.impl.RDFXMLParser.parse(RDFXMLParser.java:151)
at com.hp.hpl.jena.rdfxml.xmlinput.ARP.load(ARP.java:119)
at org.apache.jena.riot.lang.LangRDFXML.parse(LangRDFXML.java:139)
at 
org.apache.jena.riot.RDFParserRegistry$ReaderRIOTLang.read(RDFParserRegistry.java:185)
at org.apache.jena.riot.RDFDataMgr.process(RDFDataMgr.java:906)
at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:257)
at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:243)
at 
org.apache.jena.riot.adapters.RDFReaderRIOT.read(RDFReaderRIOT.java:70)
at com.hp.hpl.jena.rdf.model.impl.ModelCom.read(ModelCom.java:277)
at jena.rdfcat.readInput(rdfcat.java:374)
at jena.rdfcat$ReadAction.run(rdfcat.java:556)
at jena.rdfcat.go(rdfcat.java:282)
at jena.rdfcat.main(rdfcat.java:260)

$ echo '  ' | rdfcat -n -
http://www.w3.org/1999/02/22-rdf-syntax-ns#";
xmlns:j.0="file:///opt/jena-fuseki-1.0.2/">
  

  

{noformat}

> -n with /dev/stdin works, too. Using /dev/stdin with no format option blows 
> up, though. (It's not silently ignored like - was)

{noformat}
$ echo '  ' | rdfcat -n /dev/stdin 
http://www.w3.org/1999/02/22-rdf-syntax-ns#";
xmlns:j.0="file:///dev/">
  

  


$ echo '  ' | rdfcat /dev/stdin 
SNAPSHOT-ser

[jira] [Commented] (JENA-662) Wrong space handling in FileModelAssembler

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259841#comment-14259841
 ] 

Bruno P. Kinoshita commented on JENA-662:
-

Not sure if there's a consensus on whether FileModelAssembler should decode the 
directory name or not. But I've made a pull request that fixes the behaviour 
described in this issue. It simply calls URLDecoder.decode(s, "UTF-8"). 

> Wrong space handling in FileModelAssembler
> --
>
> Key: JENA-662
> URL: https://issues.apache.org/jira/browse/JENA-662
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Jena
>Affects Versions: Jena 2.11.1
>Reporter: Natanael Arndt
>Priority: Minor
>
> The method {{getDirectoryName}} in 
> {{com.hp.hpl.jena.assembler.assemblers.FileModelAssembler}} should also make 
> sure that at some chars, like space should be urldecoded again. E.g. If the 
> URI is {{file:///tmp/file%20name%20with%20space}} the corresponding file can 
> not be found under {{/tmp/file%20name%20with%20space}} but under  {{/tmp/file 
> name with space}}.
> There might be some other chars which have to be taken into account, e.g. 
> "%25" -> "%", but I don't think a urldecode over the whole string is correct.
> Sorry I can't provide an example yet, because I couldn't isolate this part of 
> the code so far and I didn't try to write a test for this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14268654#comment-14268654
 ] 

Bruno P. Kinoshita commented on JENA-632:
-

Hello

The grammar has been 
[updated|https://github.com/kinow/jena/commit/ad17a099a1c5fb6577a02edc311ff8ceeaa08183#diff-a55ff4fd4c62d2b74b34605f07294920]
 and it now supports the following syntax:

{noformat}
JSON { "name": ?name } WHERE { ?name ?a ?b } LIMIT 3
{noformat}

The {{LOOKAHEAD(2)}} is no longer necessary, thanks to Andy's suggestion :-) 
and I now, after changing it, find JSON easier to understand and avoid mistakes 
than SELECT JSON.

{noformat}
[1] QueryUnit::= Query
[2] Query   ::= Prologue ( SelectQuery | ConstructQuery | DescribeQuery 
| AskQuery | JsonQuery ) ValuesClause
[...] ...
{noformat}

Q1) Does that look correct?

I've debugged it, and found that, considering that this grammar is correct for 
what is proposed in this issue, the next step would be update 
{{SPARQL_Query#executeQuery()}}, and prepare the [JSON 
result|https://github.com/kinow/jena/blob/99ff26d52cdaaca4a4094c247a161349c9f500f4/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_Query.java#L328].

I'm temped to re-use what SPARQL_Query does when the query type is select, and 
simply replace the variable names by the ones provided by the user. i.e.

{noformat}
JSON { "name": ?abcde } WHERE { ?abcde ?a ?b }
{noformat}

In the example above, I'd replace the var "abcde" by "name" before serializing 
the result. 

Q2) Does that sound like a good plan?

Talking about the serialization... in Fuseki, users define the serialization 
type (xml, text/plan, json, etc). 

Q3) Should we enforce JSON when the user uses a JSON query? I think it is not 
necessary, maybe we can simply return the result set with the changed variables.

Q4) And finally, is it safe and correct to use the {{JSONOutput#format}} to 
return the result of the JSON query? I think the result will be similar to:

**query:**

{noformat}
JSON { "name": ?a } WHERE { ?a ?b ?c }
{noformat}

**result:**

{noformat}
{
  "head": {
"vars": [ "name" ]
  } ,
  "results": {
"bindings": [
  {
"name": { "type": "uri" , "value": "http://example.org/book/book5"; }
  } ,
  {
"name": { "type": "uri" , "value": "http://example.org/book/book5"; }
  } ,
  {
"name": { "type": "uri" , "value": "http://example.org/book/book3"; }
  }
]
  }
}
{noformat}

Reading the old comments here and the post in the fist comment, I think maybe 
we should use something new (or add some new method somewhere) to return 
something close to:

{noformat}
{
  "head": {
"vars": [ "name" ]
  } ,
  "results": {
"bindings": [
  {
  "name": "http://example.org/book/book5";
  },
  {
  "name": "http://example.org/book/book5";
  },
  {
  "name": "http://example.org/book/book3";
  }
]
  }
}
{noformat}

Thanks!

> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Priority: Minor
>  Labels: gsoc, java, javacc
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL) 
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user 
> community, basic understanding of HTTP and content negotiation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14272917#comment-14272917
 ] 

Bruno P. Kinoshita commented on JENA-632:
-

Hi Andy! Thanks for the detailed response. Lots of things to learn. I'll need 
some time to digest it and learn other parts of the code, so I'll probably 
continue to read the docs, look at the other smaller issues in the atlas 
submodule, arq, and other parts. But I'll update this issue as soon as I've 
done some progress. 

Learning is always exciting, and this issue seems to require working with many 
different parts of the project :-) 

Thanks again! 
Bruno

> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Priority: Minor
>  Labels: java, javacc
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL) 
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user 
> community, basic understanding of HTTP and content negotiation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-700) Add SPARQL Transaction support to Fuseki

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275165#comment-14275165
 ] 

Bruno P. Kinoshita commented on JENA-700:
-

+1, voted for this issue in JIRA. I'm not really aware of what's going on in 
the draft specification or in other issues, but in a PHP app I had to do 
something like SELECT / DELETE / UPDATE (DELETE+INSERT) / INSERT, and found 
this issue after googling for SPARQL transaction.

Let me know if you need some help (specially with testing).

Thanks!

> Add SPARQL Transaction support to Fuseki
> 
>
> Key: JENA-700
> URL: https://issues.apache.org/jira/browse/JENA-700
> Project: Apache Jena
>  Issue Type: New Feature
>  Components: Fuseki, TDB
>Reporter: Stephen Allen
>Assignee: Stephen Allen
>
> Design and implement support for remote transactions for Fuseki query and 
> update endpoints (also the GSP endpoint).  This would be specified as an 
> extension to the SPARQL 1.1 Protocol.
> A draft of the design is located at 
> \[[sparql11-transaction|http://people.apache.org/~sallen/sparql11-transaction/]\].
> Support will be added to {{jena-client}} (see JENA-226) for remote 
> repositories, and could also be added to {{jena-jdbc}} for remote connections.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-700) Add SPARQL Transaction support to Fuseki

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275312#comment-14275312
 ] 

Bruno P. Kinoshita commented on JENA-700:
-

Oh, really? Good thing I'm working exactly on this part of the code at the 
moment. I'll try to use a single HTTP operation Andy. Thanks!!!

> Add SPARQL Transaction support to Fuseki
> 
>
> Key: JENA-700
> URL: https://issues.apache.org/jira/browse/JENA-700
> Project: Apache Jena
>  Issue Type: New Feature
>  Components: Fuseki, TDB
>Reporter: Stephen Allen
>Assignee: Stephen Allen
>
> Design and implement support for remote transactions for Fuseki query and 
> update endpoints (also the GSP endpoint).  This would be specified as an 
> extension to the SPARQL 1.1 Protocol.
> A draft of the design is located at 
> \[[sparql11-transaction|http://people.apache.org/~sallen/sparql11-transaction/]\].
> Support will be added to {{jena-client}} (see JENA-226) for remote 
> repositories, and could also be added to {{jena-jdbc}} for remote connections.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-700) Add SPARQL Transaction support to Fuseki

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275354#comment-14275354
 ] 

Bruno P. Kinoshita commented on JENA-700:
-

It worked! Thanks Andy!

In case anyone needs, there is an example 
[here|http://www.w3.org/TR/sparql11-protocol/#update-urlencoded-multi].

Much simpler now. 

> Add SPARQL Transaction support to Fuseki
> 
>
> Key: JENA-700
> URL: https://issues.apache.org/jira/browse/JENA-700
> Project: Apache Jena
>  Issue Type: New Feature
>  Components: Fuseki, TDB
>Reporter: Stephen Allen
>Assignee: Stephen Allen
>
> Design and implement support for remote transactions for Fuseki query and 
> update endpoints (also the GSP endpoint).  This would be specified as an 
> extension to the SPARQL 1.1 Protocol.
> A draft of the design is located at 
> \[[sparql11-transaction|http://people.apache.org/~sallen/sparql11-transaction/]\].
> Support will be added to {{jena-client}} (see JENA-226) for remote 
> repositories, and could also be added to {{jena-jdbc}} for remote connections.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275368#comment-14275368
 ] 

Bruno P. Kinoshita commented on JENA-632:
-

>  If you'd like to draw up a list of items that need to be done, then I'll 
> pick off those that are to do with the grungey details of wiring out the 
> overall system.

Yay, sure Andy. I can do that.

> A first intermediate step might be to get parser-print working.

I'll try to summarize what needs to be done, and while I work on that I'll take 
a look at parser-print :-) 

> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Priority: Minor
>  Labels: java, javacc
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL) 
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user 
> community, basic understanding of HTTP and content negotiation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14277458#comment-14277458
 ] 

Bruno P. Kinoshita commented on JENA-632:
-

Hi! 

I have [updated the 
grammar|https://github.com/kinow/jena/commit/d628f687884eb850586f292ae329f0f78f279827#diff-a55ff4fd4c62d2b74b34605f07294920R344]
 to support what was suggested earlier for Json Values: Var() | String() | 
[Number()|https://github.com/kinow/jena/commit/d628f687884eb850586f292ae329f0f78f279827#diff-a55ff4fd4c62d2b74b34605f07294920R2139],

> QueryExectuion can have a new execJson (better name?) to make this
class of query a new, top level type. SPARQL_Query#executeQuery then
have 

[Done|https://github.com/kinow/jena/commit/6496b5737b5ed19d7153456aa4e85c642c073804#diff-caab4477912b5d49d30ffc2450d7fe84R360]!
 More or less like that?

> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Priority: Minor
>  Labels: java, javacc
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL) 
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user 
> community, basic understanding of HTTP and content negotiation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14277477#comment-14277477
 ] 

Bruno P. Kinoshita commented on JENA-632:
-

Here's the list of what I think are the remaining activities:

{panel:title=My 
Title|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
* Change Fuseki and ConNeg to offer the JSON query response to the user 
(probably as application/json or render as text/plan if requested by the user 
to do so
* Implement 
[QueryEngineHTTP#execJson()|https://github.com/kinow/jena/commit/6496b5737b5ed19d7153456aa4e85c642c073804#diff-f0b98891296edc9e882850c7bcadf6fcR499]?
* Get parser-print working (as suggested above)
* Work on how to handle large datasets and streaming. I'm [starting to build a 
JsonArray from the 
QueryIterator|https://github.com/kinow/jena/commit/6496b5737b5ed19d7153456aa4e85c642c073804#diff-caab4477912b5d49d30ffc2450d7fe84R367],
 but probably that's wrong? 
* Write unit tests
* Get user/other devs feedback in the mailing-list?
{panel}

Anything else?

> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Priority: Minor
>  Labels: java, javacc
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL) 
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user 
> community, basic understanding of HTTP and content negotiation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-853) teste Apache Jena

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14283141#comment-14283141
 ] 

Bruno P. Kinoshita commented on JENA-853:
-

Hi Andy. I've seen some issues like this at Commons and some other Apache 
projects (try googling "teste" site:issues.apache.org). This looks like spam, 
and cab probably be closed.

> teste Apache Jena
> -
>
> Key: JENA-853
> URL: https://issues.apache.org/jira/browse/JENA-853
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Jena
>Affects Versions: Jena 2.12.1
>Reporter: marco antonio lima
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-869) Fuseki2: Can't reuse dataset name after DELETE

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299788#comment-14299788
 ] 

Bruno P. Kinoshita commented on JENA-869:
-

Successfully reproduced the issue with Ubuntu 14.04, Java 7 and running Fuseki 
2 from Eclipse while debugging it. 

> Fuseki2: Can't reuse dataset name after DELETE
> --
>
> Key: JENA-869
> URL: https://issues.apache.org/jira/browse/JENA-869
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Fuseki 2.0.0
> Environment: Docker 
> https://registry.hub.docker.com/u/stain/jena-fuseki/
>Reporter: Stian Soiland-Reyes
> Fix For: Fuseki 2.0.0
>
>
> In the web interface, I create a persistent dataset "test1". I then remove 
> it. I then create a second one called "test1". Everything works fine.
> However, if I restart Fuseki, now it attemps to register test1 twice:
> {code}
> [2015-01-28 12:47:33] ServletINFO  Initializing Shiro environment
> [2015-01-28 12:47:33] Config INFO  Shiro file: file:///fuseki/shiro.ini
> [2015-01-28 12:47:33] BuilderINFO  Service: TDB test1
> [2015-01-28 12:47:34] BuilderINFO  Service: TDB test1
> [2015-01-28 12:47:34] BuilderINFO  Service: :service1
> [2015-01-28 12:47:34] BuilderINFO  Service: TDB test3
> [2015-01-28 12:47:34] Config INFO  Register: /test1
> [2015-01-28 12:47:34] Config INFO  Register: /test1
> [2015-01-28 12:47:34] Server ERROR Exception in initialization: Already 
> registered: /test1
> [2015-01-28 12:47:34] WebAppContext WARN  Failed startup of context 
> o.e.j.w.WebAppContext@d04ca48{/,file:/jena-fuseki/webapp/,STARTING}
> org.apache.jena.fuseki.FusekiException: Already registered: /test1
>   at 
> org.apache.jena.fuseki.server.DataAccessPointRegistry.register(DataAccessPointRegistry.java:28)
>   at 
> org.apache.jena.fuseki.server.FusekiServer.enable(FusekiServer.java:232)
>   at 
> org.apache.jena.fuseki.server.FusekiServer.initializeDataAccessPoints(FusekiServer.java:226)
>   at 
> org.apache.jena.fuseki.server.FusekiServerListener.init(FusekiServerListener.java:70)
>   at 
> org.apache.jena.fuseki.server.FusekiServerListener.contextInitialized(FusekiServerListener.java:45)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:799)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:446)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:296)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1347)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:492)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:117)
>   at org.eclipse.jetty.server.Server.start(Server.java:355)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:99)
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:60)
>   at org.eclipse.jetty.server.Server.doStart(Server.java:324)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
>   at org.apache.jena.fuseki.jetty.JettyFuseki.start(JettyFuseki.java:137)
>   at 
> org.apache.jena.fuseki.cmd.FusekiCmd$FusekiCmdInner.exec(FusekiCmd.java:331)
>   at arq.cmdline.CmdMain.mainMethod(CmdMain.java:102)
>   at arq.cmdline.CmdMain.mainRun(CmdMain.java:63)
>   at arq.cmdline.CmdMain.mainRun(CmdMain.java:50)
>   at 
> org.apache.jena.fuseki.cmd.FusekiCmd$FusekiCmdInner.innerMain(FusekiCmd.java:97)
>   at org.apache.jena.fuseki.cmd.FusekiCmd.main(FusekiCmd.java:60)
> {code}
> In the HTTP log from before:
> {code}
> [2015-01-28 12:47:02] Admin  INFO  [1] GET http://localhost:3031/$/server
> [2015-01-28 12:47:02] Admin  INFO  [1] 200 OK (11 ms) 
> [2015-01-28 12:47:04] Admin  INFO  [2] GET http://localhost:3031/$/server
> [2015-01-28 12:47:04] Admin  INFO  [2] 200 OK (1 ms) 
> [2015-01-28 12:47:08] Admin  INFO  [3] POST 
> http://localhost:3031/$/datasets
> [2015-01-28 12:47:08] Admin  INFO  [3] Create database : name = /test1
> [2015-01-28 12:47:08] BuilderINFO  Service: TDB test1
> [2015-01-28 12:47:08] Admin  INFO  [3] 200 OK (499 ms) 
> [2015-01-28 12:47:09] Admin  INFO  [4] GET http://localhost:3031/$/server
> [2015-01-28 12:47:0

[jira] [Commented] (JENA-869) Fuseki2: Can't reuse dataset name after DELETE

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299830#comment-14299830
 ] 

Bruno P. Kinoshita commented on JENA-869:
-

If I understand it correct, FusekiServer will try to load databases from a) 
server config, b) configuration directory and c) system directory databases 
(e.g. /home/kinow/java/jena/jena/jena-fuseki2/jena-fuseki-core/run). When 
databases are created using the Web interface, they go into the system 
directory. 

When we create the database "test1", a directory "/test1" is created under the 
system directory. However, deleting the database using the Web interface does 
not remove the directory. Recreating a test1 database again will reuse the 
existing directory. It will append the new database graph into the existing 
database. 

The old "test1" is still there with its old UUID, and the new "test1" database 
will be there as well, but with a different UUID. When the FusekiServer looks 
for databases in the system directory (the c) step in the first paragraph), it 
will query with SPARQL the model found in that directory, and will find two 
test1 databases, both in the Active state. 

Trying to load that twice, DataAccessPointRegistry will trigger the error 
reporter. 

Possible solutions include:

* When deleting a database (see ActionDatasets#execDeleteItem) we look for its 
directory under the system directory and remove it if existing

* When creating a new database, we can check if the file already exists and 
create a new name (appending -2 for example). We would need to change the 
execDeleteItem to mark the graph as inactive too though.

I'd adopt for the former alternative. Thoughts or other alternatives?

> Fuseki2: Can't reuse dataset name after DELETE
> --
>
> Key: JENA-869
> URL: https://issues.apache.org/jira/browse/JENA-869
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Fuseki 2.0.0
> Environment: Docker 
> https://registry.hub.docker.com/u/stain/jena-fuseki/
>Reporter: Stian Soiland-Reyes
> Fix For: Fuseki 2.0.0
>
>
> In the web interface, I create a persistent dataset "test1". I then remove 
> it. I then create a second one called "test1". Everything works fine.
> However, if I restart Fuseki, now it attemps to register test1 twice:
> {code}
> [2015-01-28 12:47:33] ServletINFO  Initializing Shiro environment
> [2015-01-28 12:47:33] Config INFO  Shiro file: file:///fuseki/shiro.ini
> [2015-01-28 12:47:33] BuilderINFO  Service: TDB test1
> [2015-01-28 12:47:34] BuilderINFO  Service: TDB test1
> [2015-01-28 12:47:34] BuilderINFO  Service: :service1
> [2015-01-28 12:47:34] BuilderINFO  Service: TDB test3
> [2015-01-28 12:47:34] Config INFO  Register: /test1
> [2015-01-28 12:47:34] Config INFO  Register: /test1
> [2015-01-28 12:47:34] Server ERROR Exception in initialization: Already 
> registered: /test1
> [2015-01-28 12:47:34] WebAppContext WARN  Failed startup of context 
> o.e.j.w.WebAppContext@d04ca48{/,file:/jena-fuseki/webapp/,STARTING}
> org.apache.jena.fuseki.FusekiException: Already registered: /test1
>   at 
> org.apache.jena.fuseki.server.DataAccessPointRegistry.register(DataAccessPointRegistry.java:28)
>   at 
> org.apache.jena.fuseki.server.FusekiServer.enable(FusekiServer.java:232)
>   at 
> org.apache.jena.fuseki.server.FusekiServer.initializeDataAccessPoints(FusekiServer.java:226)
>   at 
> org.apache.jena.fuseki.server.FusekiServerListener.init(FusekiServerListener.java:70)
>   at 
> org.apache.jena.fuseki.server.FusekiServerListener.contextInitialized(FusekiServerListener.java:45)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:799)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:446)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:296)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1347)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:492)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:117)
>   at org.eclipse.jetty.server.Server.start(Server.java:355)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:99)
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.do

[jira] [Commented] (JENA-869) Fuseki2: Can't reuse dataset name after DELETE

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14303063#comment-14303063
 ] 

Bruno P. Kinoshita commented on JENA-869:
-

Hi Andy!

> The first step is to define what "Delete" means. Is it remove from server?

I was thinking of simply deleting the folder in the server. When I created a 
database using the Fuseki2 UI, I debugged until this part of the code

https://github.com/apache/jena/blob/c49fae8231ab9cb21d91f24254a39c3c2f568135/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/base/file/Location.java#L165

where the database directory was created. Deleting the database using the 
Fuseki2 UI does not remove the folder. 

In the end I'd use something like {{FileUtils.deleteDirectory(new 
File("$SERVER_HOME/$DATABASE_NAME"));}}

> Fuseki2: Can't reuse dataset name after DELETE
> --
>
> Key: JENA-869
> URL: https://issues.apache.org/jira/browse/JENA-869
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Fuseki 2.0.0
> Environment: Docker 
> https://registry.hub.docker.com/u/stain/jena-fuseki/
>Reporter: Stian Soiland-Reyes
> Fix For: Fuseki 2.0.0
>
>
> In the web interface, I create a persistent dataset "test1". I then remove 
> it. I then create a second one called "test1". Everything works fine.
> However, if I restart Fuseki, now it attemps to register test1 twice:
> {code}
> [2015-01-28 12:47:33] ServletINFO  Initializing Shiro environment
> [2015-01-28 12:47:33] Config INFO  Shiro file: file:///fuseki/shiro.ini
> [2015-01-28 12:47:33] BuilderINFO  Service: TDB test1
> [2015-01-28 12:47:34] BuilderINFO  Service: TDB test1
> [2015-01-28 12:47:34] BuilderINFO  Service: :service1
> [2015-01-28 12:47:34] BuilderINFO  Service: TDB test3
> [2015-01-28 12:47:34] Config INFO  Register: /test1
> [2015-01-28 12:47:34] Config INFO  Register: /test1
> [2015-01-28 12:47:34] Server ERROR Exception in initialization: Already 
> registered: /test1
> [2015-01-28 12:47:34] WebAppContext WARN  Failed startup of context 
> o.e.j.w.WebAppContext@d04ca48{/,file:/jena-fuseki/webapp/,STARTING}
> org.apache.jena.fuseki.FusekiException: Already registered: /test1
>   at 
> org.apache.jena.fuseki.server.DataAccessPointRegistry.register(DataAccessPointRegistry.java:28)
>   at 
> org.apache.jena.fuseki.server.FusekiServer.enable(FusekiServer.java:232)
>   at 
> org.apache.jena.fuseki.server.FusekiServer.initializeDataAccessPoints(FusekiServer.java:226)
>   at 
> org.apache.jena.fuseki.server.FusekiServerListener.init(FusekiServerListener.java:70)
>   at 
> org.apache.jena.fuseki.server.FusekiServerListener.contextInitialized(FusekiServerListener.java:45)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:799)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:446)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:296)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1347)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:492)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:117)
>   at org.eclipse.jetty.server.Server.start(Server.java:355)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:99)
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:60)
>   at org.eclipse.jetty.server.Server.doStart(Server.java:324)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
>   at org.apache.jena.fuseki.jetty.JettyFuseki.start(JettyFuseki.java:137)
>   at 
> org.apache.jena.fuseki.cmd.FusekiCmd$FusekiCmdInner.exec(FusekiCmd.java:331)
>   at arq.cmdline.CmdMain.mainMethod(CmdMain.java:102)
>   at arq.cmdline.CmdMain.mainRun(CmdMain.java:63)
>   at arq.cmdline.CmdMain.mainRun(CmdMain.java:50)
>   at 
> org.apache.jena.fuseki.cmd.FusekiCmd$FusekiCmdInner.innerMain(FusekiCmd.java:97)
>   at org.apache.jena.fuseki.cmd.FusekiCmd.main(FusekiCmd.java:60)
> {code}
> In the HTTP log from before:
> {code}
> [2015-01-28 12:47:02] Admin  INFO  [1] GET http://localhost:3031/$/server
> [2015-01-28 12:47:02] Admin  INFO  [1] 200 OK (11 ms) 
> [2015-01-28 12:47:04] Admin   

[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14317408#comment-14317408
 ] 

Bruno P. Kinoshita commented on JENA-632:
-

Using the {{books.ttl}} example dataset, and the following query:

{code:title=query-sparql.sparql|borderStyle=solid}
PREFIX purl: 
PREFIX w3:  
PREFIX :  

SELECT ?author ?title 
WHERE 
{
?book purl:creator ?author .
?book purl:title ?title . 
FILTER (?author = 'J.K. Rowling')
}
{code}

Produces the following result set.

{code}

| author | title   |

| "J.K. Rowling" | "Harry Potter and the Order of the Phoenix" |
| "J.K. Rowling" | "Harry Potter and the Philosopher's Stone"  |
| "J.K. Rowling" | "Harry Potter and the Half-Blood Prince"|
| "J.K. Rowling" | "Harry Potter and the Deathly Hallows"  |

{code}

And the JSON query.

{code:title=query-json.sparql|borderStyle=solid}
PREFIX purl: 
PREFIX w3:  
PREFIX :  

JSON {
"author": ?author, 
"title": ?title 
}
WHERE 
{
?book purl:creator ?author .
?book purl:title ?title . 
FILTER (?author = 'J.K. Rowling')
}
{code}

Produces:

{code}
[ { 
"author" : "J.K. Rowling" ,
"title" : "Harry Potter and the Order of the Phoenix"
  } ,
  { 
"author" : "J.K. Rowling" ,
"title" : "Harry Potter and the Philosopher's Stone"
  } ,
  { 
"author" : "J.K. Rowling" ,
"title" : "Harry Potter and the Half-Blood Prince"
  } ,
  { 
"author" : "J.K. Rowling" ,
"title" : "Harry Potter and the Deathly Hallows"
  }
]
{code}

How are we supposed to handle this kind of data set in JSON queries? 

> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Priority: Minor
>  Labels: java, javacc
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL) 
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user 
> community, basic understanding of HTTP and content negotiation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14320034#comment-14320034
 ] 

Bruno P. Kinoshita commented on JENA-632:
-

Oh, yeah? If so that's easier than I thought. I thought we would provide some 
mechanism/syntax to have an output like:

{noformat}
[ { 
"author" : "J.K. Rowling" ,
"title" : [
"Harry Potter and the Order of the Phoenix", 
"Harry Potter and the Philosopher's Stone",
"Harry Potter and the Half-Blood Prince",
"Harry Potter and the Deathly Hallows"
]
  }
]
{noformat}

> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Priority: Minor
>  Labels: java, javacc
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL) 
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user 
> community, basic understanding of HTTP and content negotiation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14321155#comment-14321155
 ] 

Bruno P. Kinoshita commented on JENA-632:
-

>I have seen attempt to produce more complex JSON from RDF. They have their 
>place but so does a direct, simple, efficient format.
>One row, one JSON object. Streamed if the underlying query execution streams.

Good point! Thanks Andy!

> To produce that title array, the code would need to see the whole result set 
> (very special case - know there is only repeated "title", and only one 
> "author" – just expressing that is complicated enough. If the condition is 
> broken mid result set, we end up with the "HTTP 200" already sent problem).

I was preparing to try some ways to aggregate the titles into a single array, 
and look for ways of doing that. But very happy I asked here before. Let's do 
the simpler way, introduce the new JSON statement, write tests, docs, and then 
see if we need other more complex methods.

Thanks a lot Andy! Going to use some spare time in this Carnival to work on 
this issue :D
Bruno

> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Priority: Minor
>  Labels: java, javacc
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL) 
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user 
> community, basic understanding of HTTP and content negotiation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14321742#comment-14321742
 ] 

Bruno P. Kinoshita commented on JENA-632:
-

Followed the example of execSelect, and used a ResultSet wrapping the 
QueryIterator. This way, we were able to reuse existing classes. The resulting 
JSON is as follows: 

{noformat}
{
  "head": {
"vars": [ "author" , "title" ]
  } ,
  "results": {
"bindings": [
  {
"author": { "type": "literal" , "value": "J.K. Rowling" } ,
"title": { "type": "literal" , "value": "Harry Potter and the Order of 
the Phoenix" }
  } ,
  {
"author": { "type": "literal" , "value": "J.K. Rowling" } ,
"title": { "type": "literal" , "value": "Harry Potter and the 
Philosopher's Stone" }
  } ,
  {
"author": { "type": "literal" , "value": "J.K. Rowling" } ,
"title": { "type": "literal" , "value": "Harry Potter and the 
Half-Blood Prince" }
  } ,
  {
"author": { "type": "literal" , "value": "J.K. Rowling" } ,
"title": { "type": "literal" , "value": "Harry Potter and the Deathly 
Hallows" }
  }
]
  }
}
{noformat}

Here are some GitHub links to the mentioned code:

New result set - 
https://github.com/kinow/jena/blob/ae7c50f0f313b7dfa1cd8333fb0072f89e5972c5/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/ResultSetJsonStream.java#L37

The new method that gets called by SPARQL and builds a ResultSetJsonStream - 
https://github.com/kinow/jena/blob/ae7c50f0f313b7dfa1cd8333fb0072f89e5972c5/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/QueryExecutionBase.java#L390

I'm waiting until we have settled down on the API details to start writing 
tests and documentation.

Thanks!

> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Priority: Minor
>  Labels: java, javacc
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL) 
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user 
> community, basic understanding of HTTP and content negotiation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14326857#comment-14326857
 ] 

Bruno P. Kinoshita commented on JENA-632:
-

Hi Andy! Sorry for the delay. Sounds good to me. I should have followed your 
initial suggestion of starting by doing the streaming version first :-) I will 
take a look at {{JSWriter}} and will try to come up with an update in the next 
days.

Thanks!

> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Priority: Minor
>  Labels: java, javacc
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL) 
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user 
> community, basic understanding of HTTP and content negotiation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327613#comment-14327613
 ] 

Bruno P. Kinoshita commented on JENA-632:
-

Hi again,

Here's the updated code 
https://github.com/kinow/jena/commit/7b3b10134f4201314d5f6c6103a595181e82f997

I noticed that I have been updating several imports (Eclipse auto-removes the 
space before the {{;}}). I'll try to fix it before preparing the code for a 
merge.

Here's how I used the {{JSWriter}} 
https://github.com/kinow/jena/commit/7b3b10134f4201314d5f6c6103a595181e82f997#diff-c42503247148fd09663639cb9df2e641R693

And here's the new output:

{noformat}
[ { 
  "author" : "J.K. Rowling" ,
  "title" : "Harry Potter and the Order of the Phoenix"
}
{ 
  "author" : "J.K. Rowling" ,
  "title" : "Harry Potter and the Philosopher's Stone"
}
{ 
  "author" : "J.K. Rowling" ,
  "title" : "Harry Potter and the Half-Blood Prince"
}
{ 
  "author" : "J.K. Rowling" ,
  "title" : "Harry Potter and the Deathly Hallows"
}
 ]
{noformat}


> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Priority: Minor
>  Labels: java, javacc
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL) 
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user 
> community, basic understanding of HTTP and content negotiation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-896) Remove ReleaseNotes.txt from releases

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361873#comment-14361873
 ] 

Bruno P. Kinoshita commented on JENA-896:
-

+1 for a simplified build process and avoid repeated tasks. 

I think the fixed URL that Stian suggests is probably something similar to this 
http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/releasenotes.html?

Or maybe we could use the Changes Report Plug-in with Maven? As in Commons Lang 
http://commons.apache.org/proper/commons-lang/changes-report.html.

I am not really familiar with Jena build, so I am just throwing ideas here :-)

> Remove ReleaseNotes.txt from releases
> -
>
> Key: JENA-896
> URL: https://issues.apache.org/jira/browse/JENA-896
> Project: Apache Jena
>  Issue Type: Task
>  Components: Documentation, Web site
>Affects Versions: Jena 2.13.0
>Reporter: Stian Soiland-Reyes
>
> The [release notes of 2.13.0 
> RC1|https://github.com/apache/jena/blob/ecaa41eefdcb79f16bd4b9525b89309f8282ca47/jena-core/ReleaseNotes.txt]
>  were not updated to mention 2.13.0
> It was [suggested for future 
> releases|http://mail-archives.apache.org/mod_mbox/jena-dev/201503.mbox/%3C54FD8D9D.8020206%40apache.org%3E]
>  to remove these ReleaseNotes from the releases as they require manual 
> updating - and instead include a fixed URL to page(s) that describes the 
> change log. This may be an auto-generated page in Jira or a page on the 
> website, with links to Jira.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-900) fuseki-security need writing.

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361875#comment-14361875
 ] 

Bruno P. Kinoshita commented on JENA-900:
-

I am not familiar with Fuseki security, and it would be a good opportunity to 
learn more about it. I can help reviewing or writing the docs, as well as 
testing if necessary :)

> fuseki-security need writing.
> -
>
> Key: JENA-900
> URL: https://issues.apache.org/jira/browse/JENA-900
> Project: Apache Jena
>  Issue Type: Task
>  Components: Fuseki
>Affects Versions: Fuseki 2.0.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>
> The fuseki2/fuseki-security page needs some placeholder text soon and a 
> proper writing as and when.  Key brief instructions are for setting the Ui to 
> accessible from other than localhost.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-896) Remove ReleaseNotes.txt from releases

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361882#comment-14361882
 ] 

Bruno P. Kinoshita commented on JENA-896:
-

>For Commons Lang, is it driven from JIRA as well, or a "changes.xml"?

changes.xml, we have to update it every time we fix some issue or add new 
enhancement to the project.

> Making release as lightweight as possible, encourages us to release more 
> frequently. None of this is a huge burden but every little adds and things 
> rarely are removed.

+1, lots of people that have played the role of release manage in Commons have 
complained about its release process (though I have never done before), so I 
believe you are right in trying to make it as lightweight and automated as 
possible.

> Remove ReleaseNotes.txt from releases
> -
>
> Key: JENA-896
> URL: https://issues.apache.org/jira/browse/JENA-896
> Project: Apache Jena
>  Issue Type: Task
>  Components: Documentation, Web site
>Affects Versions: Jena 2.13.0
>Reporter: Stian Soiland-Reyes
>
> The [release notes of 2.13.0 
> RC1|https://github.com/apache/jena/blob/ecaa41eefdcb79f16bd4b9525b89309f8282ca47/jena-core/ReleaseNotes.txt]
>  were not updated to mention 2.13.0
> It was [suggested for future 
> releases|http://mail-archives.apache.org/mod_mbox/jena-dev/201503.mbox/%3C54FD8D9D.8020206%40apache.org%3E]
>  to remove these ReleaseNotes from the releases as they require manual 
> updating - and instead include a fixed URL to page(s) that describes the 
> change log. This may be an auto-generated page in Jira or a page on the 
> website, with links to Jira.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-902) Default cache sizes too large / configurability should be more exposed

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361913#comment-14361913
 ] 

Bruno P. Kinoshita commented on JENA-902:
-

> Proposed is to lower the default settings

I will leave this one to the the others that will have a better background on 
this default value.

>  have a more exposed documentation as to tuning the memory settings of TDB.

We can probably add something in one of the [TDB 
page|http://jena.apache.org/documentation/tdb/index.html] sub pages. My 
suggestion is include somewhere in the [TDB configuration 
page|http://jena.apache.org/documentation/tdb/configuration.html]. What do you 
think? Would you be able to produce a patch, or maybe even some draft here? 


> Default cache sizes too large / configurability should be more exposed
> --
>
> Key: JENA-902
> URL: https://issues.apache.org/jira/browse/JENA-902
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: TDB
>Affects Versions: TDB 1.1.0
>Reporter: Jan De Beer
>
> In the class "com.hp.hpl.jena.tdb.sys.SystemTDB" there are two important 
> cache size settings, namely "Node2NodeIdCacheSize" and 
> "NodeId2NodeCacheSize". On a 64-bit platform, they default to 10 and 
> 50 entries.
> In our setup of 5 TDB-backed graphs inside a single dataset, these default 
> settings led to out-of-memory errors of the Fuseki server although setting 
> the available heap memory to 3GB. It took some heap analysis to reveal that 
> these two caches were the main memory consumers. Also, from the public 
> documentation of Fuseki / TDB, it wasn't so obvious that their sizes can be 
> configured. Only by looking into the source code, we found that one can use a 
> TDB properties file to override the defaults.
> Proposed is to lower the default settings and have a more exposed 
> documentation as to tuning the memory settings of TDB.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-896) Remove ReleaseNotes.txt from releases

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361927#comment-14361927
 ] 

Bruno P. Kinoshita commented on JENA-896:
-

I had a look at Apache Hadoop's 
[HowToRelease](http://wiki.apache.org/hadoop/HowToRelease) documentation, and 
they use a Python script (relnotes.py) to query JIRA and create the 
releasenotes.html. 

Here is the gist of this [modified script for 
Jena](https://gist.github.com/anonymous/3f9b6ebcc71f982e2e3e).

It produced a simple HTML, but that I think can be as useful - maybe even more 
since it has the description - than our existing ReleaseNotes.txt. What do you 
think? Attaching the 2.11.1 releasenotes.html. Maybe we could further adapt it 
to take into consideration the component, and generate one report pert 
component? 

Cheers

> Remove ReleaseNotes.txt from releases
> -
>
> Key: JENA-896
> URL: https://issues.apache.org/jira/browse/JENA-896
> Project: Apache Jena
>  Issue Type: Task
>  Components: Documentation, Web site
>Affects Versions: Jena 2.13.0
>Reporter: Stian Soiland-Reyes
>
> The [release notes of 2.13.0 
> RC1|https://github.com/apache/jena/blob/ecaa41eefdcb79f16bd4b9525b89309f8282ca47/jena-core/ReleaseNotes.txt]
>  were not updated to mention 2.13.0
> It was [suggested for future 
> releases|http://mail-archives.apache.org/mod_mbox/jena-dev/201503.mbox/%3C54FD8D9D.8020206%40apache.org%3E]
>  to remove these ReleaseNotes from the releases as they require manual 
> updating - and instead include a fixed URL to page(s) that describes the 
> change log. This may be an auto-generated page in Jira or a page on the 
> website, with links to Jira.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-896) Remove ReleaseNotes.txt from releases

[Bruno P. Kinoshita (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated JENA-896:

Attachment: releasenotes.JENA.Jena 2.11.1.html

2.11.1 release notes generated with Hadoop's utility Python script.

> Remove ReleaseNotes.txt from releases
> -
>
> Key: JENA-896
> URL: https://issues.apache.org/jira/browse/JENA-896
> Project: Apache Jena
>  Issue Type: Task
>  Components: Documentation, Web site
>Affects Versions: Jena 2.13.0
>Reporter: Stian Soiland-Reyes
> Attachments: releasenotes.JENA.Jena 2.11.1.html
>
>
> The [release notes of 2.13.0 
> RC1|https://github.com/apache/jena/blob/ecaa41eefdcb79f16bd4b9525b89309f8282ca47/jena-core/ReleaseNotes.txt]
>  were not updated to mention 2.13.0
> It was [suggested for future 
> releases|http://mail-archives.apache.org/mod_mbox/jena-dev/201503.mbox/%3C54FD8D9D.8020206%40apache.org%3E]
>  to remove these ReleaseNotes from the releases as they require manual 
> updating - and instead include a fixed URL to page(s) that describes the 
> change log. This may be an auto-generated page in Jira or a page on the 
> website, with links to Jira.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)