[jira] [Commented] (JENA-1434) Allow warnings to be treated as errors by RIOT
[
https://issues.apache.org/jira/browse/JENA-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16269492#comment-16269492
]
Ian Dickinson commented on JENA-1434:
-
Thanks all!
Ian
> Allow warnings to be treated as errors by RIOT
> --
>
> Key: JENA-1434
> URL: https://issues.apache.org/jira/browse/JENA-1434
> Project: Apache Jena
> Issue Type: Improvement
> Components: RIOT
>Affects Versions: Jena 3.5.0
>Reporter: Ian Dickinson
>Assignee: Rob Vesse
> Fix For: Jena 3.6.0
>
>
> I would like to use `riot --validate` as part of an integration test for a
> system that generates Turtle. Ideally, the exit status for the riot command
> would be non-zero, indicating a problem, if the input was not valid. However,
> I see an exit status of zero always:
> {noformat}
> $ riot --validate alert.ttl && echo 'exit status is: ' $?
> 13:50:37 WARN riot :: [line: 39, col: 25] Lexical form
> '2017-03-19T00:00:00+00:00' not valid for datatype XSD date
> 13:50:37 WARN riot :: [line: 42, col: 20] Lexical form ''
> not valid for datatype XSD date
> 13:50:37 WARN riot :: [line: 58, col: 20] Lexical form ''
> not valid for datatype XSD date
> exit status is: 0
> {noformat}
> Version info:
> {noformat}
> $ riot --version
> Jena: VERSION: 3.5.0
> Jena: BUILD_DATE: 2017-10-30T09:20:28+
> RIOT: VERSION: 3.5.0
> RIOT: BUILD_DATE: 2017-10-30T09:20:28+
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JENA-1434) Set exit status code when riot is running in --validate mode
[
https://issues.apache.org/jira/browse/JENA-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16264497#comment-16264497
]
Ian Dickinson commented on JENA-1434:
-
Thanks Rob. It appears that `--stop` only works for error, not warnings:
{noformat}
ian@ian-desktop $ riot --validate --stop temp/alert.ttl
15:49:12 WARN riot :: [line: 39, col: 25] Lexical form
'2017-03-19T00:00:00+00:00' not valid for datatype XSD date
15:49:12 WARN riot :: [line: 42, col: 20] Lexical form '' not
valid for datatype XSD date
15:49:12 WARN riot :: [line: 47, col: 25] Lexical form
'2017-11-19T00:00:00+00:00' not valid for datatype XSD date
15:49:12 WARN riot :: [line: 50, col: 20] Lexical form '' not
valid for datatype XSD date
15:49:12 WARN riot :: [line: 55, col: 25] Lexical form
'2017-02-20T00:00:00+00:00' not valid for datatype XSD date
15:49:12 WARN riot :: [line: 58, col: 20] Lexical form '' not
valid for datatype XSD date
ian@ian-desktop $ echo $?
0
{noformat}
I would still argue that, when you specifically ask for validation with
--validate, a non-zero termination status is warranted even for warnings.
Different status values could be used for warnings and for errors.
> Set exit status code when riot is running in --validate mode
>
>
> Key: JENA-1434
> URL: https://issues.apache.org/jira/browse/JENA-1434
> Project: Apache Jena
> Issue Type: Improvement
> Components: RIOT
>Affects Versions: Jena 3.5.0
>Reporter: Ian Dickinson
>Assignee: Rob Vesse
>
> I would like to use `riot --validate` as part of an integration test for a
> system that generates Turtle. Ideally, the exit status for the riot command
> would be non-zero, indicating a problem, if the input was not valid. However,
> I see an exit status of zero always:
> {noformat}
> $ riot --validate alert.ttl && echo 'exit status is: ' $?
> 13:50:37 WARN riot :: [line: 39, col: 25] Lexical form
> '2017-03-19T00:00:00+00:00' not valid for datatype XSD date
> 13:50:37 WARN riot :: [line: 42, col: 20] Lexical form ''
> not valid for datatype XSD date
> 13:50:37 WARN riot :: [line: 58, col: 20] Lexical form ''
> not valid for datatype XSD date
> exit status is: 0
> {noformat}
> Version info:
> {noformat}
> $ riot --version
> Jena: VERSION: 3.5.0
> Jena: BUILD_DATE: 2017-10-30T09:20:28+
> RIOT: VERSION: 3.5.0
> RIOT: BUILD_DATE: 2017-10-30T09:20:28+
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JENA-1434) Set exit status code when riot is running in --validate mode
Ian Dickinson created JENA-1434:
---
Summary: Set exit status code when riot is running in --validate
mode
Key: JENA-1434
URL: https://issues.apache.org/jira/browse/JENA-1434
Project: Apache Jena
Issue Type: Improvement
Components: RIOT
Affects Versions: Jena 3.5.0
Reporter: Ian Dickinson
I would like to use `riot --validate` as part of an integration test for a
system that generates Turtle. Ideally, the exit status for the riot command
would be non-zero, indicating a problem, if the input was not valid. However, I
see an exit status of zero always:
{noformat}
$ riot --validate alert.ttl && echo 'exit status is: ' $?
13:50:37 WARN riot :: [line: 39, col: 25] Lexical form
'2017-03-19T00:00:00+00:00' not valid for datatype XSD date
13:50:37 WARN riot :: [line: 42, col: 20] Lexical form '' not
valid for datatype XSD date
13:50:37 WARN riot :: [line: 58, col: 20] Lexical form '' not
valid for datatype XSD date
exit status is: 0
{noformat}
Version info:
{noformat}
$ riot --version
Jena: VERSION: 3.5.0
Jena: BUILD_DATE: 2017-10-30T09:20:28+
RIOT: VERSION: 3.5.0
RIOT: BUILD_DATE: 2017-10-30T09:20:28+
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JENA-890) Pivot table in Fuseki2 has confusing design and user experience
[ https://issues.apache.org/jira/browse/JENA-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14349638#comment-14349638 ] Ian Dickinson commented on JENA-890: That's an interesting take, thanks. I wonder if it's worth us taking a step back and thinking about what the goal for Fuseki is, or could be(come). And probably doing it on dev@, rather than on this issue thread! Fwiw, my instinct is to keep focussed on a simple interface that does a good job of managing datasets. Some level of query is a natural part of that process - after I've loaded data, I may want to inspect it to make sure I've done my job correctly. But (imho) what the user of this Fuseki cares about is effectively managing data: loading, monitoring, backing up, performance testing, and security, and doing that effectively, simply and reliably. An alternative view is that Fuseki is an 'out-of-the-box' tool to help get people going on their RDF/linked-data journey. These users problaby don't care so much about managing complex collections of datasets, but want a one-stop shop to load, query and explore their data. Another view is that serious production users want all of the basic management capability, plus the tools to diagnose queries that don't work as expected, monitor usage patterns, etc. Or another is that Fuseki is a 'lite' BI tool for RDF and linked data: load your data, and generate reports and dataviz that allow you to explore data and discover its value. And doubtless many others. It isn't that any one of these is undesirable - I've had situations where I would have loved every capability on the above list. To me, it's at least in-part, a question of keeping focus and avoiding creeping bloatware. One tool *could* do all this and more, but I think that tool would become fat, complex, hard to maintain and harder to use. Treading the Protege path, for example, is something I would want to avoid. Pivot table in Fuseki2 has confusing design and user experience --- Key: JENA-890 URL: https://issues.apache.org/jira/browse/JENA-890 Project: Apache Jena Issue Type: Improvement Components: Fuseki Affects Versions: Fuseki 2.0.0 Reporter: Ian Dickinson The SPARQL query tab on the Fuseki2 interface has an option in the results pane labelled 'pivot table'. It's very, very unclear what this does. It appears to be an experimental feature of some kind, but it does not provide a clear, discoverable user experience. In fact, after playing with it for some minutes, I still can't figure out what it is actually for. I suggest that either the UX of this feature is radically improved, or we remove it from Fuseki2 until it is ready for wider exposure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-890) Pivot table in Fuseki2 has confusing design and user experience
[ https://issues.apache.org/jira/browse/JENA-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14349611#comment-14349611 ] Ian Dickinson commented on JENA-890: I'm going to ignore your absurd straw man argument, except to note that it's not an effective way to participate in a collaborative discussion. I'm happy to have a reasoned discussion; I don't care about bluster. To the actual point: it doesn't really matter whether you spent 45 seconds or 45 minutes writing a paragraph of explanatory text - people in general won't read it. There's plenty of research to back that up. Here's a sample: http://www.nngroup.com/articles/satisficing/ http://www.nngroup.com/articles/how-users-read-on-the-web/ http://www.uxbooth.com/articles/10-usability-lessons-from-steve-krugs-dont-make-me-think/ notes 1-3 http://guidelines.usability.gov/guidelines/172 Pivot table in Fuseki2 has confusing design and user experience --- Key: JENA-890 URL: https://issues.apache.org/jira/browse/JENA-890 Project: Apache Jena Issue Type: Improvement Components: Fuseki Affects Versions: Fuseki 2.0.0 Reporter: Ian Dickinson The SPARQL query tab on the Fuseki2 interface has an option in the results pane labelled 'pivot table'. It's very, very unclear what this does. It appears to be an experimental feature of some kind, but it does not provide a clear, discoverable user experience. In fact, after playing with it for some minutes, I still can't figure out what it is actually for. I suggest that either the UX of this feature is radically improved, or we remove it from Fuseki2 until it is ready for wider exposure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-890) Pivot table in Fuseki2 has confusing design and user experience
[ https://issues.apache.org/jira/browse/JENA-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14347937#comment-14347937 ] Ian Dickinson commented on JENA-890: That's a remarkable example of a simple instruction text. I'm afraid I stick to my point. Pivot tables have their place, no doubt, but it's far from clear to me that the base dataset management tool is that place. And surely anyone who requires the full capability of Yasr can just run their own Yasgui instance, no? Pivot table in Fuseki2 has confusing design and user experience --- Key: JENA-890 URL: https://issues.apache.org/jira/browse/JENA-890 Project: Apache Jena Issue Type: Improvement Components: Fuseki Affects Versions: Fuseki 2.0.0 Reporter: Ian Dickinson The SPARQL query tab on the Fuseki2 interface has an option in the results pane labelled 'pivot table'. It's very, very unclear what this does. It appears to be an experimental feature of some kind, but it does not provide a clear, discoverable user experience. In fact, after playing with it for some minutes, I still can't figure out what it is actually for. I suggest that either the UX of this feature is radically improved, or we remove it from Fuseki2 until it is ready for wider exposure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-890) Pivot table in Fuseki2 has confusing design and user experience
[ https://issues.apache.org/jira/browse/JENA-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14345384#comment-14345384 ] Ian Dickinson commented on JENA-890: Sorry, but what's the use case for having analysis and charting tools in Fuseki at all? I totally get that such things can be useful for some users in some contexts, and I'm all for people experimenting with RDF-based dataviz workbenches, but Fuseki is a dataset control and publishing UI. It should, in my opinion, be focussed on doing that task well. I'm not, in general, in favour of adding user-configurable options to UI's. I strongly recommend Steve Krug's book on this topic (http://www.amazon.co.uk/Dont-Make-Me-Think-Usability/dp/0321965515/ref=asap_bc?ie=UTF8). Whenever as a developer you put a user configuration option in a UI, you're doubling the test surface of the system, but moreover you're making the user do the hard work of figuring out what the right behaviour should be for you. Pivot table in Fuseki2 has confusing design and user experience --- Key: JENA-890 URL: https://issues.apache.org/jira/browse/JENA-890 Project: Apache Jena Issue Type: Improvement Components: Fuseki Affects Versions: Fuseki 2.0.0 Reporter: Ian Dickinson The SPARQL query tab on the Fuseki2 interface has an option in the results pane labelled 'pivot table'. It's very, very unclear what this does. It appears to be an experimental feature of some kind, but it does not provide a clear, discoverable user experience. In fact, after playing with it for some minutes, I still can't figure out what it is actually for. I suggest that either the UX of this feature is radically improved, or we remove it from Fuseki2 until it is ready for wider exposure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-890) Pivot table in Fuseki2 has confusing design and user experience
[ https://issues.apache.org/jira/browse/JENA-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14345385#comment-14345385 ] Ian Dickinson commented on JENA-890: Happy to feed back comments to upstream. The pivot table isn't the only problem with Yasgui, but it is the worst. Pivot table in Fuseki2 has confusing design and user experience --- Key: JENA-890 URL: https://issues.apache.org/jira/browse/JENA-890 Project: Apache Jena Issue Type: Improvement Components: Fuseki Affects Versions: Fuseki 2.0.0 Reporter: Ian Dickinson The SPARQL query tab on the Fuseki2 interface has an option in the results pane labelled 'pivot table'. It's very, very unclear what this does. It appears to be an experimental feature of some kind, but it does not provide a clear, discoverable user experience. In fact, after playing with it for some minutes, I still can't figure out what it is actually for. I suggest that either the UX of this feature is radically improved, or we remove it from Fuseki2 until it is ready for wider exposure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-890) Pivot table in Fuseki2 has confusing design and user experience
[ https://issues.apache.org/jira/browse/JENA-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14345394#comment-14345394 ] Ian Dickinson commented on JENA-890: (is this blocker for the release?) Do you mean a blocker or the blocker? There are a number of problems with the recent clutch of changes to Fuseki2 - I'm working on fixing them but I'm also very busy with client work. I'll start a separate thread on dev@ to discuss. Pivot table in Fuseki2 has confusing design and user experience --- Key: JENA-890 URL: https://issues.apache.org/jira/browse/JENA-890 Project: Apache Jena Issue Type: Improvement Components: Fuseki Affects Versions: Fuseki 2.0.0 Reporter: Ian Dickinson The SPARQL query tab on the Fuseki2 interface has an option in the results pane labelled 'pivot table'. It's very, very unclear what this does. It appears to be an experimental feature of some kind, but it does not provide a clear, discoverable user experience. In fact, after playing with it for some minutes, I still can't figure out what it is actually for. I suggest that either the UX of this feature is radically improved, or we remove it from Fuseki2 until it is ready for wider exposure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-890) Pivot table in Fuseki2 has confusing design and user experience
[ https://issues.apache.org/jira/browse/JENA-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14344687#comment-14344687 ] Ian Dickinson commented on JENA-890: anecdotally I figured it out in a couple of minutes That, right there, is a perfect illustration of a non-discoverable user interface. If it takes the user several minutes to figure out, and is easier with prior experience of a reference tool that itself is quite complex, then clearly it's not aimed at the general user. Fuseki is not an RDF analysis and charting tool. That's a great thing for someone to develop, but it's a separate research and development activity. Fuseki should simply do a good job of providing a UI for people to manage the serving of RDF data via HTTP. Pivot table in Fuseki2 has confusing design and user experience --- Key: JENA-890 URL: https://issues.apache.org/jira/browse/JENA-890 Project: Apache Jena Issue Type: Improvement Components: Fuseki Affects Versions: Fuseki 2.0.0 Reporter: Ian Dickinson The SPARQL query tab on the Fuseki2 interface has an option in the results pane labelled 'pivot table'. It's very, very unclear what this does. It appears to be an experimental feature of some kind, but it does not provide a clear, discoverable user experience. In fact, after playing with it for some minutes, I still can't figure out what it is actually for. I suggest that either the UX of this feature is radically improved, or we remove it from Fuseki2 until it is ready for wider exposure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JENA-890) Pivot table in Fuseki2 has confusing design and user experience
Ian Dickinson created JENA-890: -- Summary: Pivot table in Fuseki2 has confusing design and user experience Key: JENA-890 URL: https://issues.apache.org/jira/browse/JENA-890 Project: Apache Jena Issue Type: Improvement Components: Fuseki Affects Versions: Fuseki 2.0.0 Reporter: Ian Dickinson The SPARQL query tab on the Fuseki2 interface has an option in the results pane labelled 'pivot table'. It's very, very unclear what this does. It appears to be an experimental feature of some kind, but it does not provide a clear, discoverable user experience. In fact, after playing with it for some minutes, I still can't figure out what it is actually for. I suggest that either the UX of this feature is radically improved, or we remove it from Fuseki2 until it is ready for wider exposure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JENA-737) Deleting a dataset has stopped working
Ian Dickinson created JENA-737:
--
Summary: Deleting a dataset has stopped working
Key: JENA-737
URL: https://issues.apache.org/jira/browse/JENA-737
Project: Apache Jena
Issue Type: Bug
Components: Fuseki
Reporter: Ian Dickinson
Priority: Minor
Deleting a dataset using the HTTP DELETE verb isn't working (or I've got it
wrong). I think the following sequence used to work in Fuseki2, but now is
returning a 400 error:
{code}
$ curl http://localhost:3030/$/datasets/foo
{
ds.name : /foo ,
ds.services : [
{
srv.description : Graph Store Protocol (Read) ,
srv.endpoints : [ get ] ,
srv.type : GSP_R
} ,
{
srv.description : HTTP Quads ,
srv.endpoints : [ ] ,
srv.type : Quads
} ,
{
srv.description : Graph Store Protocol ,
srv.endpoints : [ data ] ,
srv.type : GSP
} ,
{
srv.description : SPARQL Update ,
srv.endpoints : [ update ] ,
srv.type : Update
} ,
{
srv.description : SPARQL Query ,
srv.endpoints : [
sparql ,
query
] ,
srv.type : Query
} ,
{
srv.description : File Upload ,
srv.endpoints : [ upload ] ,
srv.type : Upload
}
] ,
ds.state : true
}
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl -XDELETE -v http://localhost:3030/$/datasets/foo
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 3030 (#0)
DELETE /$/datasets/foo HTTP/1.1
User-Agent: curl/7.35.0
Host: localhost:3030
Accept: */*
HTTP/1.1 400 Failed to find dataset for '/foo'
Fuseki-Request-ID: 224
Access-Control-Allow-Origin: *
* Server Fuseki (2.0.0.M2-SNAPSHOT) is not blacklisted
Server: Fuseki (2.0.0.M2-SNAPSHOT)
Content-Length: 0
* Connection #0 to host localhost left intact
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (JENA-738) HTTP PUT to GSP endpoint should replace existing content?
Ian Dickinson created JENA-738:
--
Summary: HTTP PUT to GSP endpoint should replace existing content?
Key: JENA-738
URL: https://issues.apache.org/jira/browse/JENA-738
Project: Apache Jena
Issue Type: Improvement
Components: Fuseki
Reporter: Ian Dickinson
Priority: Minor
Partly a question, and partly a suggestion for improvement: should HTTP PUT to
the /data endpoint replace existing content in the graph? I'd like to suggest
that it does, for the following reasons:
* we already have POST to /data to add new content
* it seems more consistent with the HTTP spec
* it would support the use-case of 'get the current graph contents, edit it,
put it back'
Here's a test case:
{noformat}
ian@ian-desktop $ curl http://localhost:3030/foo/data
{
}
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl -XPUT -v -d 'http://example/foo http://example/p
http://example/a.' -H 'Content-Type: text/turtle'
http://localhost:3030/foo/data
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 3030 (#0)
PUT /foo/data HTTP/1.1
User-Agent: curl/7.35.0
Host: localhost:3030
Accept: */*
Content-Type: text/turtle
Content-Length: 59
* upload completely sent off: 59 out of 59 bytes
HTTP/1.1 200 OK
Fuseki-Request-ID: 235
Access-Control-Allow-Origin: *
* Server Fuseki (2.0.0.M2-SNAPSHOT) is not blacklisted
Server: Fuseki (2.0.0.M2-SNAPSHOT)
Content-Type: application/json
Transfer-Encoding: chunked
{
count : 1 ,
quadCount : 0 ,
tripleCount : 1
}
* Connection #0 to host localhost left intact
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl http://localhost:3030/foo/data
{ http://example/foo
http://example/p http://example/a .
}
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl -XPUT -v -d 'http://example/foo http://example/p
http://example/b.' -H 'Content-Type: text/turtle'
http://localhost:3030/foo/data
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 3030 (#0)
PUT /foo/data HTTP/1.1
User-Agent: curl/7.35.0
Host: localhost:3030
Accept: */*
Content-Type: text/turtle
Content-Length: 59
* upload completely sent off: 59 out of 59 bytes
HTTP/1.1 200 OK
Fuseki-Request-ID: 237
Access-Control-Allow-Origin: *
* Server Fuseki (2.0.0.M2-SNAPSHOT) is not blacklisted
Server: Fuseki (2.0.0.M2-SNAPSHOT)
Content-Type: application/json
Transfer-Encoding: chunked
{
count : 1 ,
quadCount : 0 ,
tripleCount : 1
}
* Connection #0 to host localhost left intact
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl http://localhost:3030/foo/data
{ http://example/foo
http://example/p http://example/b , http://example/a .
}
{noformat}
What I am suggesting is that the final GET returns a graph of one triple: :foo
\:p :b
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (JENA-737) Deleting a dataset has stopped working
[
https://issues.apache.org/jira/browse/JENA-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Dickinson updated JENA-737:
---
Description:
Deleting a dataset using the HTTP DELETE verb isn't working (or I've got it
wrong). I think the following sequence used to work in Fuseki2, but now is
returning a 400 error:
{noformat}
$ curl http://localhost:3030/$/datasets/foo
{
ds.name : /foo ,
ds.services : [
{
srv.description : Graph Store Protocol (Read) ,
srv.endpoints : [ get ] ,
srv.type : GSP_R
} ,
{
srv.description : HTTP Quads ,
srv.endpoints : [ ] ,
srv.type : Quads
} ,
{
srv.description : Graph Store Protocol ,
srv.endpoints : [ data ] ,
srv.type : GSP
} ,
{
srv.description : SPARQL Update ,
srv.endpoints : [ update ] ,
srv.type : Update
} ,
{
srv.description : SPARQL Query ,
srv.endpoints : [
sparql ,
query
] ,
srv.type : Query
} ,
{
srv.description : File Upload ,
srv.endpoints : [ upload ] ,
srv.type : Upload
}
] ,
ds.state : true
}
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl -XDELETE -v http://localhost:3030/$/datasets/foo
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 3030 (#0)
DELETE /$/datasets/foo HTTP/1.1
User-Agent: curl/7.35.0
Host: localhost:3030
Accept: */*
HTTP/1.1 400 Failed to find dataset for '/foo'
Fuseki-Request-ID: 224
Access-Control-Allow-Origin: *
* Server Fuseki (2.0.0.M2-SNAPSHOT) is not blacklisted
Server: Fuseki (2.0.0.M2-SNAPSHOT)
Content-Length: 0
* Connection #0 to host localhost left intact
{noformat}
was:
Deleting a dataset using the HTTP DELETE verb isn't working (or I've got it
wrong). I think the following sequence used to work in Fuseki2, but now is
returning a 400 error:
{code}
$ curl http://localhost:3030/$/datasets/foo
{
ds.name : /foo ,
ds.services : [
{
srv.description : Graph Store Protocol (Read) ,
srv.endpoints : [ get ] ,
srv.type : GSP_R
} ,
{
srv.description : HTTP Quads ,
srv.endpoints : [ ] ,
srv.type : Quads
} ,
{
srv.description : Graph Store Protocol ,
srv.endpoints : [ data ] ,
srv.type : GSP
} ,
{
srv.description : SPARQL Update ,
srv.endpoints : [ update ] ,
srv.type : Update
} ,
{
srv.description : SPARQL Query ,
srv.endpoints : [
sparql ,
query
] ,
srv.type : Query
} ,
{
srv.description : File Upload ,
srv.endpoints : [ upload ] ,
srv.type : Upload
}
] ,
ds.state : true
}
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl -XDELETE -v http://localhost:3030/$/datasets/foo
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 3030 (#0)
DELETE /$/datasets/foo HTTP/1.1
User-Agent: curl/7.35.0
Host: localhost:3030
Accept: */*
HTTP/1.1 400 Failed to find dataset for '/foo'
Fuseki-Request-ID: 224
Access-Control-Allow-Origin: *
* Server Fuseki (2.0.0.M2-SNAPSHOT) is not blacklisted
Server: Fuseki (2.0.0.M2-SNAPSHOT)
Content-Length: 0
* Connection #0 to host localhost left intact
{code}
Deleting a dataset has stopped working
--
Key: JENA-737
URL: https://issues.apache.org/jira/browse/JENA-737
Project: Apache Jena
Issue Type: Bug
Components: Fuseki
Reporter: Ian Dickinson
Priority: Minor
Labels: fuseki2
Deleting a dataset using the HTTP DELETE verb isn't working (or I've got it
wrong). I think the following sequence used to work in Fuseki2, but now is
returning a 400 error:
{noformat}
$ curl http://localhost:3030/$/datasets/foo
{
ds.name : /foo ,
ds.services : [
{
srv.description : Graph Store Protocol (Read) ,
srv.endpoints : [ get ] ,
srv.type : GSP_R
} ,
{
srv.description : HTTP Quads ,
srv.endpoints : [ ] ,
srv.type : Quads
} ,
{
srv.description : Graph Store Protocol ,
srv.endpoints : [ data ] ,
srv.type : GSP
} ,
{
srv.description : SPARQL Update ,
srv.endpoints : [ update ] ,
srv.type : Update
} ,
{
srv.description : SPARQL Query ,
srv.endpoints : [
sparql ,
query
] ,
srv.type : Query
} ,
{
srv.description : File Upload ,
srv.endpoints : [ upload ] ,
srv.type : Upload
[jira] [Commented] (JENA-738) HTTP PUT to GSP endpoint should replace existing content?
[
https://issues.apache.org/jira/browse/JENA-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14051391#comment-14051391
]
Ian Dickinson commented on JENA-738:
{quote}
In your example, it's {{PUT}} on {{/ds/data}} is a quads operation and it
clears the dataset . All named graphs will be removed.
If you want per graph control, it'll need to use {{?default}} or {{?graph=...}}
{quote}
Ah, good point. Thanks!
HTTP PUT to GSP endpoint should replace existing content?
-
Key: JENA-738
URL: https://issues.apache.org/jira/browse/JENA-738
Project: Apache Jena
Issue Type: Bug
Components: Fuseki
Reporter: Ian Dickinson
Labels: fuseki2
Partly a question, and partly a suggestion for improvement: should HTTP PUT
to the /data endpoint replace existing content in the graph? I'd like to
suggest that it does, for the following reasons:
* we already have POST to /data to add new content
* it seems more consistent with the HTTP spec
* it would support the use-case of 'get the current graph contents, edit it,
put it back'
Here's a test case:
{noformat}
ian@ian-desktop $ curl http://localhost:3030/foo/data
{
}
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl -XPUT -v -d 'http://example/foo http://example/p
http://example/a.' -H 'Content-Type: text/turtle'
http://localhost:3030/foo/data
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 3030 (#0)
PUT /foo/data HTTP/1.1
User-Agent: curl/7.35.0
Host: localhost:3030
Accept: */*
Content-Type: text/turtle
Content-Length: 59
* upload completely sent off: 59 out of 59 bytes
HTTP/1.1 200 OK
Fuseki-Request-ID: 235
Access-Control-Allow-Origin: *
* Server Fuseki (2.0.0.M2-SNAPSHOT) is not blacklisted
Server: Fuseki (2.0.0.M2-SNAPSHOT)
Content-Type: application/json
Transfer-Encoding: chunked
{
count : 1 ,
quadCount : 0 ,
tripleCount : 1
}
* Connection #0 to host localhost left intact
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl http://localhost:3030/foo/data
{ http://example/foo
http://example/p http://example/a .
}
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl -XPUT -v -d 'http://example/foo http://example/p
http://example/b.' -H 'Content-Type: text/turtle'
http://localhost:3030/foo/data
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 3030 (#0)
PUT /foo/data HTTP/1.1
User-Agent: curl/7.35.0
Host: localhost:3030
Accept: */*
Content-Type: text/turtle
Content-Length: 59
* upload completely sent off: 59 out of 59 bytes
HTTP/1.1 200 OK
Fuseki-Request-ID: 237
Access-Control-Allow-Origin: *
* Server Fuseki (2.0.0.M2-SNAPSHOT) is not blacklisted
Server: Fuseki (2.0.0.M2-SNAPSHOT)
Content-Type: application/json
Transfer-Encoding: chunked
{
count : 1 ,
quadCount : 0 ,
tripleCount : 1
}
* Connection #0 to host localhost left intact
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl http://localhost:3030/foo/data
{ http://example/foo
http://example/p http://example/b , http://example/a .
}
{noformat}
What I am suggesting is that the final GET returns a graph of one triple:
:foo \:p :b
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JENA-737) Deleting a dataset has stopped working
[
https://issues.apache.org/jira/browse/JENA-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14051529#comment-14051529
]
Ian Dickinson commented on JENA-737:
Hi Rob,
I think one of the things we have yet to discover is the right balance between
convenience and protecting users from themselves. Yes delete could be a one-way
street to er, I probably didn't mean that-ville, but there are lots of other
side-effecting operations: uploading a file to a dataset, editing the contents
of a graph, etc. In principle (though afaik this isn't working at the moment),
the Qonsole should allow people to run SPARQL update commands. I'm loathe to
turn off-by-default every action that could potentially do something that
someone might regret, but which other people would find useful.
You're absolutely right that the intent is that Shiro will be the way to
control who gets to do which operations. That part of Fuseki2 is - at best -
underdeveloped at the moment! We could do with some solid user stories to
design and test against.
For the time being, I propose that we leave the (potentially) dangerous
operations enabled, and get some experience/user feedback. And figure out how
the Shiro stuff would work out in practice!
Another thing to think about - no advocacy, just an idea - would be to have
development and production modes like a Rails server.
Deleting a dataset has stopped working
--
Key: JENA-737
URL: https://issues.apache.org/jira/browse/JENA-737
Project: Apache Jena
Issue Type: Bug
Components: Fuseki
Reporter: Ian Dickinson
Assignee: Andy Seaborne
Priority: Minor
Labels: fuseki2
Deleting a dataset using the HTTP DELETE verb isn't working (or I've got it
wrong). I think the following sequence used to work in Fuseki2, but now is
returning a 400 error:
{noformat}
$ curl http://localhost:3030/$/datasets/foo
{
ds.name : /foo ,
ds.services : [
{
srv.description : Graph Store Protocol (Read) ,
srv.endpoints : [ get ] ,
srv.type : GSP_R
} ,
{
srv.description : HTTP Quads ,
srv.endpoints : [ ] ,
srv.type : Quads
} ,
{
srv.description : Graph Store Protocol ,
srv.endpoints : [ data ] ,
srv.type : GSP
} ,
{
srv.description : SPARQL Update ,
srv.endpoints : [ update ] ,
srv.type : Update
} ,
{
srv.description : SPARQL Query ,
srv.endpoints : [
sparql ,
query
] ,
srv.type : Query
} ,
{
srv.description : File Upload ,
srv.endpoints : [ upload ] ,
srv.type : Upload
}
] ,
ds.state : true
}
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl -XDELETE -v http://localhost:3030/$/datasets/foo
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 3030 (#0)
DELETE /$/datasets/foo HTTP/1.1
User-Agent: curl/7.35.0
Host: localhost:3030
Accept: */*
HTTP/1.1 400 Failed to find dataset for '/foo'
Fuseki-Request-ID: 224
Access-Control-Allow-Origin: *
* Server Fuseki (2.0.0.M2-SNAPSHOT) is not blacklisted
Server: Fuseki (2.0.0.M2-SNAPSHOT)
Content-Length: 0
* Connection #0 to host localhost left intact
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JENA-731) schemagen does not add the generated source directory to the source roots
[ https://issues.apache.org/jira/browse/JENA-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14045909#comment-14045909 ] Ian Dickinson commented on JENA-731: I think this is an improvement, not a bug. As I understood it the previous default, target/generated-sources, is already a source root by default. I'm concerned that changing the *default* output directory with no warning could break users' builds, if they have other tools that use the current output location. At the very least, this change should be documented in the changelog. schemagen does not add the generated source directory to the source roots - Key: JENA-731 URL: https://issues.apache.org/jira/browse/JENA-731 Project: Apache Jena Issue Type: Bug Components: Cmd line tools Affects Versions: Jena 2.11.2 Reporter: Benson Margulies Fix For: Jena 2.12.0 The plugin neglects to add a source root. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (JENA-722) Fuseki2: report online/offline status for dataset
Ian Dickinson created JENA-722:
--
Summary: Fuseki2: report online/offline status for dataset
Key: JENA-722
URL: https://issues.apache.org/jira/browse/JENA-722
Project: Apache Jena
Issue Type: Improvement
Components: Fuseki
Reporter: Ian Dickinson
Priority: Minor
A dataset can be switched offline by posting to
{{/$/datasets/foo?state=offline}}. This is working. It would be nice to report
the online/offline status of the dataset when listing the datasets via a get on
{{/$/datasets}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (JENA-717) Fuseki2 delete dataset not working
Ian Dickinson created JENA-717:
--
Summary: Fuseki2 delete dataset not working
Key: JENA-717
URL: https://issues.apache.org/jira/browse/JENA-717
Project: Apache Jena
Issue Type: Bug
Components: Fuseki
Reporter: Ian Dickinson
Attempting to delete a dataset with an HTTP DELETE request gives a 400 error.
Probably pilot error, but I'm not sure what I'm doing wrong:
{code}
ian@ian-desktop $ curl -i 'http://localhost:3030/$/datasets/foo'
HTTP/1.1 200 OK
Fuseki-Request-ID: 10
Access-Control-Allow-Origin: *
Server: Fuseki (2.0.0.M2-SNAPSHOT)
Vary: Accept,Accept-Encoding,Accept-Charset
Content-Type: application/json
Transfer-Encoding: chunked
{
ds.name : /foo ,
ds.services : [
{
srv.endpoints : [ get ] ,
srv.type : graph store protocol (Read)
} ,
{
srv.endpoints : [ update ] ,
srv.type : update
} ,
{
srv.endpoints : [ ] ,
srv.type : Quads
} ,
{
srv.endpoints : [ data ] ,
srv.type : graph store protocol
} ,
{
srv.endpoints : [
sparql ,
query
] ,
srv.type : query
} ,
{
srv.endpoints : [ upload ] ,
srv.type : upload
}
]
}
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl -i -X DELETE http://localhost:3030/$/datasets/foo
HTTP/1.1 400 Failed to find dataset for '/foo'
Fuseki-Request-ID: 11
Access-Control-Allow-Origin: *
Server: Fuseki (2.0.0.M2-SNAPSHOT)
Content-Length:
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (JENA-718) Fuseki2 API: get /$/server not working
Ian Dickinson created JENA-718:
--
Summary: Fuseki2 API: get /$/server not working
Key: JENA-718
URL: https://issues.apache.org/jira/browse/JENA-718
Project: Apache Jena
Issue Type: Bug
Components: Fuseki
Reporter: Ian Dickinson
An HTTP GET to /$/server should return the current server status and endpoints,
but is currently returning 404.
{code}
ian@ian-desktop $ curl -H Accept: application/json
http://localhost:3030/$/server
Error 404: Not Found
Fuseki - version 2.0.0.M2-SNAPSHOT (Build date: ${maven.build.timestamp})
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (JENA-719) Fuseki2: report uptime as part of server status
Ian Dickinson created JENA-719: -- Summary: Fuseki2: report uptime as part of server status Key: JENA-719 URL: https://issues.apache.org/jira/browse/JENA-719 Project: Apache Jena Issue Type: Improvement Components: Fuseki Reporter: Ian Dickinson Priority: Minor It might be nice to return the server uptime as part of the /$/server status report. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (JENA-635) Add LSB init daemon support to fuseki startup script
Ian Dickinson created JENA-635: -- Summary: Add LSB init daemon support to fuseki startup script Key: JENA-635 URL: https://issues.apache.org/jira/browse/JENA-635 Project: Apache Jena Issue Type: Improvement Components: Fuseki Reporter: Ian Dickinson Priority: Minor I have made some improvements to the Fuseki startup script, so that it works more easily as an init.d service script. Specifically, I have: * allowed default values for variables to be loaded from /etc/default, so that changing local setup does not require editing the script * switched to using lsb_daemon_log rather than echo for output * added fallbacks so that echo will be used if the lsb init functions are not available * switched to using 'ps -p' rather than 'kill -0' to find out if a process is running * made the location of the PID file more flexible. This is a call for review of these changes, and in particular test reports from other environments. I have tested on Ubuntu 12.04LTS, 13.10 and 14.04. I have not tested on MaxOS, cygwin or other Linux distros, and would welcome test reports and implementation improvements. The full revised script is in a gist: https://gist.github.com/ephemerian/8802368 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (JENA-635) Add LSB init daemon support to fuseki startup script
[ https://issues.apache.org/jira/browse/JENA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson updated JENA-635: --- Assignee: Ian Dickinson Add LSB init daemon support to fuseki startup script Key: JENA-635 URL: https://issues.apache.org/jira/browse/JENA-635 Project: Apache Jena Issue Type: Improvement Components: Fuseki Reporter: Ian Dickinson Assignee: Ian Dickinson Priority: Minor I have made some improvements to the Fuseki startup script, so that it works more easily as an init.d service script. Specifically, I have: * allowed default values for variables to be loaded from /etc/default, so that changing local setup does not require editing the script * switched to using lsb_daemon_log rather than echo for output * added fallbacks so that echo will be used if the lsb init functions are not available * switched to using 'ps -p' rather than 'kill -0' to find out if a process is running * made the location of the PID file more flexible. This is a call for review of these changes, and in particular test reports from other environments. I have tested on Ubuntu 12.04LTS, 13.10 and 14.04. I have not tested on MaxOS, cygwin or other Linux distros, and would welcome test reports and implementation improvements. The full revised script is in a gist: https://gist.github.com/ephemerian/8802368 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (JENA-635) Add LSB init daemon support to fuseki startup script
[ https://issues.apache.org/jira/browse/JENA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890716#comment-13890716 ] Ian Dickinson commented on JENA-635: Good thought, I'll investigate. Add LSB init daemon support to fuseki startup script Key: JENA-635 URL: https://issues.apache.org/jira/browse/JENA-635 Project: Apache Jena Issue Type: Improvement Components: Fuseki Reporter: Ian Dickinson Assignee: Ian Dickinson Priority: Minor Attachments: fuseki-init.d.patch I have made some improvements to the Fuseki startup script, so that it works more easily as an init.d service script. Specifically, I have: * allowed default values for variables to be loaded from /etc/default, so that changing local setup does not require editing the script * switched to using lsb_daemon_log rather than echo for output * added fallbacks so that echo will be used if the lsb init functions are not available * switched to using 'ps -p' rather than 'kill -0' to find out if a process is running * made the location of the PID file more flexible. This is a call for review of these changes, and in particular test reports from other environments. I have tested on Ubuntu 12.04LTS, 13.10 and 14.04. I have not tested on MaxOS, cygwin or other Linux distros, and would welcome test reports and implementation improvements. The full revised script is in a gist: https://gist.github.com/ephemerian/8802368 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (JENA-635) Add LSB init daemon support to fuseki startup script
[ https://issues.apache.org/jira/browse/JENA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson updated JENA-635: --- Attachment: (was: fuseki-init.d.patch) Add LSB init daemon support to fuseki startup script Key: JENA-635 URL: https://issues.apache.org/jira/browse/JENA-635 Project: Apache Jena Issue Type: Improvement Components: Fuseki Reporter: Ian Dickinson Assignee: Ian Dickinson Priority: Minor Attachments: fuseki-init.d.patch I have made some improvements to the Fuseki startup script, so that it works more easily as an init.d service script. Specifically, I have: * allowed default values for variables to be loaded from /etc/default, so that changing local setup does not require editing the script * switched to using lsb_daemon_log rather than echo for output * added fallbacks so that echo will be used if the lsb init functions are not available * switched to using 'ps -p' rather than 'kill -0' to find out if a process is running * made the location of the PID file more flexible. This is a call for review of these changes, and in particular test reports from other environments. I have tested on Ubuntu 12.04LTS, 13.10 and 14.04. I have not tested on MaxOS, cygwin or other Linux distros, and would welcome test reports and implementation improvements. The full revised script is in a gist: https://gist.github.com/ephemerian/8802368 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (JENA-635) Add LSB init daemon support to fuseki startup script
[ https://issues.apache.org/jira/browse/JENA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson updated JENA-635: --- Attachment: fuseki-init.d.patch Revised to ensure that it starts from the command line Add LSB init daemon support to fuseki startup script Key: JENA-635 URL: https://issues.apache.org/jira/browse/JENA-635 Project: Apache Jena Issue Type: Improvement Components: Fuseki Reporter: Ian Dickinson Assignee: Ian Dickinson Priority: Minor Attachments: fuseki-init.d.patch I have made some improvements to the Fuseki startup script, so that it works more easily as an init.d service script. Specifically, I have: * allowed default values for variables to be loaded from /etc/default, so that changing local setup does not require editing the script * switched to using lsb_daemon_log rather than echo for output * added fallbacks so that echo will be used if the lsb init functions are not available * switched to using 'ps -p' rather than 'kill -0' to find out if a process is running * made the location of the PID file more flexible. This is a call for review of these changes, and in particular test reports from other environments. I have tested on Ubuntu 12.04LTS, 13.10 and 14.04. I have not tested on MaxOS, cygwin or other Linux distros, and would welcome test reports and implementation improvements. The full revised script is in a gist: https://gist.github.com/ephemerian/8802368 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (JENA-635) Add LSB init daemon support to fuseki startup script
[ https://issues.apache.org/jira/browse/JENA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890789#comment-13890789 ] Ian Dickinson commented on JENA-635: OK, I have checked and - for me at least - it does run from the command line. If the lsb init functions are available from the usual place it will load them, otherwise it default to using echo. I also tweaked the script so that the start file can be specified in the environment or via /etc/default Add LSB init daemon support to fuseki startup script Key: JENA-635 URL: https://issues.apache.org/jira/browse/JENA-635 Project: Apache Jena Issue Type: Improvement Components: Fuseki Reporter: Ian Dickinson Assignee: Ian Dickinson Priority: Minor Attachments: fuseki-init.d.patch I have made some improvements to the Fuseki startup script, so that it works more easily as an init.d service script. Specifically, I have: * allowed default values for variables to be loaded from /etc/default, so that changing local setup does not require editing the script * switched to using lsb_daemon_log rather than echo for output * added fallbacks so that echo will be used if the lsb init functions are not available * switched to using 'ps -p' rather than 'kill -0' to find out if a process is running * made the location of the PID file more flexible. This is a call for review of these changes, and in particular test reports from other environments. I have tested on Ubuntu 12.04LTS, 13.10 and 14.04. I have not tested on MaxOS, cygwin or other Linux distros, and would welcome test reports and implementation improvements. The full revised script is in a gist: https://gist.github.com/ephemerian/8802368 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (JENA-636) No configuration option for setting output encoding in schemagen
[ https://issues.apache.org/jira/browse/JENA-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890792#comment-13890792 ] Ian Dickinson commented on JENA-636: I should have been clearer. Yes, it's schemagen not the plugin itself - there's currently no way to set an output encoding other than platform default. The action here is to add a configuration option to schemagen, and ensure that it has an effect on the output stream! No configuration option for setting output encoding in schemagen Key: JENA-636 URL: https://issues.apache.org/jira/browse/JENA-636 Project: Apache Jena Issue Type: Bug Components: Cmd line tools Affects Versions: Jena 2.11.1 Reporter: Ian Dickinson Assignee: Ian Dickinson Priority: Minor User reported a problem that Java source files generated by schemagen are only created with character encoding cp1252, whereas his source files need to be in UTF-8 to cope with international characters in the ontology content. At present, there is no configuration option to set the character encoding on the output file, so this would need to be added to schemagen. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (JENA-596) Schemagen does not work with Maven 3.1.x
[ https://issues.apache.org/jira/browse/JENA-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson closed JENA-596. -- Schemagen does not work with Maven 3.1.x Key: JENA-596 URL: https://issues.apache.org/jira/browse/JENA-596 Project: Apache Jena Issue Type: Bug Reporter: Ian Dickinson Assignee: Ian Dickinson Fix For: Jena 2.11.1 Attachments: jena-maven-tools.patch Maven 3.1.x has changed the way that POM parameters are passed to plugin code, causing the schemagen Maven plugin to break. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (JENA-596) Schemagen does not work with Maven 3.1.x
[ https://issues.apache.org/jira/browse/JENA-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson resolved JENA-596. Resolution: Fixed Fix Version/s: Jena 2.11.1 Schemagen does not work with Maven 3.1.x Key: JENA-596 URL: https://issues.apache.org/jira/browse/JENA-596 Project: Apache Jena Issue Type: Bug Reporter: Ian Dickinson Assignee: Ian Dickinson Fix For: Jena 2.11.1 Attachments: jena-maven-tools.patch Maven 3.1.x has changed the way that POM parameters are passed to plugin code, causing the schemagen Maven plugin to break. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (JENA-596) Schemagen does not work with Maven 3.1.x
Ian Dickinson created JENA-596: -- Summary: Schemagen does not work with Maven 3.1.x Key: JENA-596 URL: https://issues.apache.org/jira/browse/JENA-596 Project: Apache Jena Issue Type: Bug Reporter: Ian Dickinson Assignee: Ian Dickinson Maven 3.1.x has changed the way that POM parameters are passed to plugin code, causing the schemagen Maven plugin to break. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-596) Schemagen does not work with Maven 3.1.x
[ https://issues.apache.org/jira/browse/JENA-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831874#comment-13831874 ] Ian Dickinson commented on JENA-596: Patch applied and committed, thank you Shane. AndyS - can you please confirm that it works for you now before I close the issue? Schemagen does not work with Maven 3.1.x Key: JENA-596 URL: https://issues.apache.org/jira/browse/JENA-596 Project: Apache Jena Issue Type: Bug Reporter: Ian Dickinson Assignee: Ian Dickinson Attachments: jena-maven-tools.patch Maven 3.1.x has changed the way that POM parameters are passed to plugin code, causing the schemagen Maven plugin to break. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-420) Web-based User Interface for Jena Fuseki
[ https://issues.apache.org/jira/browse/JENA-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13814934#comment-13814934 ] Ian Dickinson commented on JENA-420: Andy - what are the `gspRead` and `gspReadWrite` services, and why does `gspRead` not have an endpoint? Web-based User Interface for Jena Fuseki Key: JENA-420 URL: https://issues.apache.org/jira/browse/JENA-420 Project: Apache Jena Issue Type: New Feature Components: Fuseki Reporter: Stephen Allen Labels: gsoc2013, java, javascript, mentor, rdf, sparql, velocity, web Attachments: fuseki1.png, fuseki2.png, fuseki3.png, fuseki4.png Fuseki could use an overhaul / rewrite of the web interface. It would be great to design a nice web-based GUI interface for both querying/exploring the data and for managing Fuseki itself. Tools and skills that may be required: Java, HTML+CSS, Javascript, Velocity (templates used server-side in place of JSP) A few ideas to get started: 1) Resource Explorer This interface allows the user to select any resource from either a list of all triples in a graph, or from the results of a SPARQL query. After selecting the resource, they can view all of the statements that reference the resource. 2) Improved Query Input It would be great to enhance the query input form for both queries and updates. Some features here that could be useful would be an IDE-like input box that performed syntax highlighting, automatic indentation, and easy commenting out of selected lines of text. Additionally being able to pre-populate the input box with the user's commonly used prefixes would be great (stored in a cookie or some such). 3) Improved Query Results Better display of query results (especially SELECT queries). Already mentioned was a tie-in to the Resource Explorer, so a user can easily see the statements about some interesting resource in the results. But it would also be great to layout and format the result table better. Even display the results on the same page as the query input box using AJAX. Or allow the table to be resorted after the query results have been returned. Also display the total number of rows. 4) Query Management View and manage currently running queries. Display how long queries have been executing, and allow the user to cancel queries that may be taking too long. 5) Fuseki Management There are many tasks here that would be great. Expose JVM properties via JMX in a nice UI. Things like CPU/Memory usage, disk space remaining, etc. Allow initiation of back-up tasks. Allow the user to download a snapshot of the repository. Shut down the server. Possibly add and remove datasets dynamically. Attached are screenshots indicating the current UI and the workflow for issuing a query. The idea would be to overhaul and replace most of this! -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (JENA-420) Web-based User Interface for Jena Fuseki
[ https://issues.apache.org/jira/browse/JENA-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13814934#comment-13814934 ] Ian Dickinson edited comment on JENA-420 at 11/6/13 2:48 PM: - Andy - what are the gspRead and gspReadWrite services, and why does gspRead not have an endpoint? was (Author: ijd): Andy - what are the codegspRead/code and codegspReadWrite/code services, and why does codegspRead/code not have an endpoint? Web-based User Interface for Jena Fuseki Key: JENA-420 URL: https://issues.apache.org/jira/browse/JENA-420 Project: Apache Jena Issue Type: New Feature Components: Fuseki Reporter: Stephen Allen Labels: gsoc2013, java, javascript, mentor, rdf, sparql, velocity, web Attachments: fuseki1.png, fuseki2.png, fuseki3.png, fuseki4.png Fuseki could use an overhaul / rewrite of the web interface. It would be great to design a nice web-based GUI interface for both querying/exploring the data and for managing Fuseki itself. Tools and skills that may be required: Java, HTML+CSS, Javascript, Velocity (templates used server-side in place of JSP) A few ideas to get started: 1) Resource Explorer This interface allows the user to select any resource from either a list of all triples in a graph, or from the results of a SPARQL query. After selecting the resource, they can view all of the statements that reference the resource. 2) Improved Query Input It would be great to enhance the query input form for both queries and updates. Some features here that could be useful would be an IDE-like input box that performed syntax highlighting, automatic indentation, and easy commenting out of selected lines of text. Additionally being able to pre-populate the input box with the user's commonly used prefixes would be great (stored in a cookie or some such). 3) Improved Query Results Better display of query results (especially SELECT queries). Already mentioned was a tie-in to the Resource Explorer, so a user can easily see the statements about some interesting resource in the results. But it would also be great to layout and format the result table better. Even display the results on the same page as the query input box using AJAX. Or allow the table to be resorted after the query results have been returned. Also display the total number of rows. 4) Query Management View and manage currently running queries. Display how long queries have been executing, and allow the user to cancel queries that may be taking too long. 5) Fuseki Management There are many tasks here that would be great. Expose JVM properties via JMX in a nice UI. Things like CPU/Memory usage, disk space remaining, etc. Allow initiation of back-up tasks. Allow the user to download a snapshot of the repository. Shut down the server. Possibly add and remove datasets dynamically. Attached are screenshots indicating the current UI and the workflow for issuing a query. The idea would be to overhaul and replace most of this! -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-420) Web-based User Interface for Jena Fuseki
[ https://issues.apache.org/jira/browse/JENA-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13810080#comment-13810080 ] Ian Dickinson commented on JENA-420: Branch where we're working on the new UI implementation: http://svn.apache.org/repos/asf/jena/branches/jena-fuseki-new-ui/ Web-based User Interface for Jena Fuseki Key: JENA-420 URL: https://issues.apache.org/jira/browse/JENA-420 Project: Apache Jena Issue Type: New Feature Components: Fuseki Reporter: Stephen Allen Labels: gsoc2013, java, javascript, mentor, rdf, sparql, velocity, web Attachments: fuseki1.png, fuseki2.png, fuseki3.png, fuseki4.png Fuseki could use an overhaul / rewrite of the web interface. It would be great to design a nice web-based GUI interface for both querying/exploring the data and for managing Fuseki itself. Tools and skills that may be required: Java, HTML+CSS, Javascript, Velocity (templates used server-side in place of JSP) A few ideas to get started: 1) Resource Explorer This interface allows the user to select any resource from either a list of all triples in a graph, or from the results of a SPARQL query. After selecting the resource, they can view all of the statements that reference the resource. 2) Improved Query Input It would be great to enhance the query input form for both queries and updates. Some features here that could be useful would be an IDE-like input box that performed syntax highlighting, automatic indentation, and easy commenting out of selected lines of text. Additionally being able to pre-populate the input box with the user's commonly used prefixes would be great (stored in a cookie or some such). 3) Improved Query Results Better display of query results (especially SELECT queries). Already mentioned was a tie-in to the Resource Explorer, so a user can easily see the statements about some interesting resource in the results. But it would also be great to layout and format the result table better. Even display the results on the same page as the query input box using AJAX. Or allow the table to be resorted after the query results have been returned. Also display the total number of rows. 4) Query Management View and manage currently running queries. Display how long queries have been executing, and allow the user to cancel queries that may be taking too long. 5) Fuseki Management There are many tasks here that would be great. Expose JVM properties via JMX in a nice UI. Things like CPU/Memory usage, disk space remaining, etc. Allow initiation of back-up tasks. Allow the user to download a snapshot of the repository. Shut down the server. Possibly add and remove datasets dynamically. Attached are screenshots indicating the current UI and the workflow for issuing a query. The idea would be to overhaul and replace most of this! -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-482) Website re-organisation and facelift
[ https://issues.apache.org/jira/browse/JENA-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13748446#comment-13748446 ] Ian Dickinson commented on JENA-482: Hi Samuel, I like the breadcrumbs. I think keeping it on top is the right thing. It occurred to me that there's another use case that this supports, which is users arriving at the page via a search engine. They now have a much clearer idea where they are in terms of the project's information collection. I'd support Leigh's suggestion of having the version number easily visible on the web site. The use case this supports is: I'm using Jena, or thinking of doing so, and I'd like to quickly check what the latest version is. Currently, you have to go to the download link, navigate to the right folder, see which is the latest archive file and parse the version number out of the file name. Which breaks the don't make me think rule, and then some! We can easily make updating the published version number part of the release process. For similar reasons, I'd also support putting the prominent download link back in. For people who have already got started, and just need the latest version or to do a new install on another machine, the call-to-action we want is to download the software. Those comments aside, good job! I'm happy to see this go live when we roll the next Jena release. Ian Website re-organisation and facelift Key: JENA-482 URL: https://issues.apache.org/jira/browse/JENA-482 Project: Apache Jena Issue Type: Documentation Components: Web site Reporter: Samuel Croset Assignee: Rob Vesse Priority: Minor Labels: documentation Attachments: new_website.diff I've been experimenting a bit in the last couple of days over the Jena website and documentation. You can see a live demo version of the result here: http://loopasam.github.io/jena-doc/index.html My motivation was to try to make the overall browsing experience a bit clearer and nicer looking without disrupting too much what's already in place. I have refactored some of the skeleton and CSS using Twitter Bootstrap. I haven't changed any of the build mechanism (ASF-CMS), so pretty much all the documents and pages are working just as before out of the box. Before doing more work on this I wanted to know what the community thinks of it and whether it could be integrated with the current code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-482) Website re-organisation and facelift
[ https://issues.apache.org/jira/browse/JENA-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13744283#comment-13744283 ] Ian Dickinson commented on JENA-482: It's a great job, Samuel, thank you. I do think there's still a concern on second level navigation. Consider the following pages from the old and new design: http://jena.apache.org/documentation/tdb/assembler.html http://jena.staging.apache.org/documentation/tdb/assembler.html On the old site, while I'm looking at a page on TDB assembler I can still see (i) the range of other topics that I might want to dig into, in the case that TDB isn't (the only) Jena documentation I'm interested in, and (ii) some - though admittedly not all - of the other TDB topic pages. In the new design, I lose that second level context. To see the other TDB pages I have to click back, to see the other top-level documentation topics I have to go back twice. I'd be the first to admit that the old left-menu isn't perfect, and does look dated. It's imperfect because it's neither brief, nor complete. Andy and I debated this a bit back when Jena first migrated to Apache, and the current selection of topics in the nav menu is an uneasy compromise between compactness and completeness. But I think that some level of persistent second-level navigation does meet a need in the UX. There are a couple of ways we could address this. One would be to add some level of secondary navigation menu, as a second horizontal bar or a floating page menu. Another would be to add a trail with links to the next topic, previous topic and overview. Those serve different purposes, but I think either would add some useful orientation. There may be other solutions as well. Website re-organisation and facelift Key: JENA-482 URL: https://issues.apache.org/jira/browse/JENA-482 Project: Apache Jena Issue Type: Documentation Components: Web site Reporter: Samuel Croset Assignee: Rob Vesse Priority: Minor Labels: documentation Attachments: new_website.diff I've been experimenting a bit in the last couple of days over the Jena website and documentation. You can see a live demo version of the result here: http://loopasam.github.io/jena-doc/index.html My motivation was to try to make the overall browsing experience a bit clearer and nicer looking without disrupting too much what's already in place. I have refactored some of the skeleton and CSS using Twitter Bootstrap. I haven't changed any of the build mechanism (ASF-CMS), so pretty much all the documents and pages are working just as before out of the box. Before doing more work on this I wanted to know what the community thinks of it and whether it could be integrated with the current code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-482) Website re-organisation and facelift
[ https://issues.apache.org/jira/browse/JENA-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700560#comment-13700560 ] Ian Dickinson commented on JENA-482: Yes, I agree with adding a sidebar navigation once you get into the learn section. The problem is that most of the content on the site is in the page hierarchies under 'learn', so it's helpful to users to have a persistent visual reminder of where they are, and which other content categories are available to them. Without it, and just having the dropdown menu for top-level categories, it's rather disorientating. Website re-organisation and facelift Key: JENA-482 URL: https://issues.apache.org/jira/browse/JENA-482 Project: Apache Jena Issue Type: Documentation Components: Web site Reporter: Samuel Croset Priority: Minor Labels: documentation I've been experimenting a bit in the last couple of days over the Jena website and documentation. You can see a live demo version of the result here: http://loopasam.github.io/jena-doc/index.html My motivation was to try to make the overall browsing experience a bit clearer and nicer looking without disrupting too much what's already in place. I have refactored some of the skeleton and CSS using Twitter Bootstrap. I haven't changed any of the build mechanism (ASF-CMS), so pretty much all the documents and pages are working just as before out of the box. Before doing more work on this I wanted to know what the community thinks of it and whether it could be integrated with the current code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-357) rdfcat warnings appear on stdout
[ https://issues.apache.org/jira/browse/JENA-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504968#comment-13504968 ] Ian Dickinson commented on JENA-357: See http://jena.markmail.org/thread/ibhxqbsknpbaddam rdfcat warnings appear on stdout Key: JENA-357 URL: https://issues.apache.org/jira/browse/JENA-357 Project: Apache Jena Issue Type: Bug Components: Cmd line tools Affects Versions: Jena 2.7.4 Reporter: Ian Dickinson Assignee: Ian Dickinson -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JENA-353) RDFList.append doc indicates a copy is created not always so.
[ https://issues.apache.org/jira/browse/JENA-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson updated JENA-353: --- Assignee: Ian Dickinson RDFList.append doc indicates a copy is created not always so. - Key: JENA-353 URL: https://issues.apache.org/jira/browse/JENA-353 Project: Apache Jena Issue Type: Bug Affects Versions: Jena 2.7.4 Reporter: Claude Warren Assignee: Ian Dickinson Documentation for RDFList.append() indicates that a copy is created, both lists are merged into the copy and the copy returned so as to be non side-effecting operation on either this list or the given list However, in the case where this list is empty the other list is returned. I believe copy of the other should be returned in this case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-333) Using javadoc 7 causes warning exception in build (DAMLVocabulary, DAML_OIL)
[
https://issues.apache.org/jira/browse/JENA-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13468485#comment-13468485
]
Ian Dickinson commented on JENA-333:
The rest of the DAML support is long gone in Jena, so I suggest these classes
get removed as soon as practicable. At the very least we should deprecate them
this cycle and remove them next cycle. In practice, I strongly doubt anyone
would notice if we just removed them now.
In the meantime, I would like to think that it would be possible to exclude a
certain class from Javadoc generation, but a quick look at the Maven javadoc
configuration page [1] suggests that you can only exclude by package name, not
by class.
[1] http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html
Using javadoc 7 causes warning exception in build (DAMLVocabulary, DAML_OIL)
Key: JENA-333
URL: https://issues.apache.org/jira/browse/JENA-333
Project: Apache Jena
Issue Type: Bug
Components: Build, Onotology API
Affects Versions: Jena 2.7.4
Environment: Java 7 (1.7.0_07) Linux 64 bit. (but not Java 1.6.0_24)
Reporter: Andy Seaborne
Priority: Minor
Under java7, the build of jena core gets two stacktraces (marked as warning)
in javadoc production. Unclear if the javadoc output is materially affected.
The following two files are:
com/hp/hpl/jena/vocabulary/DAMLVocabulary.java
com/hp/hpl/jena/vocabulary/DAML_OIL.java
It's unclear as to whether DAML_OIL.java problems maybe due to implementing
DAMLVocabulary and nothing more.
/usr/lib/jvm/java-7-openjdk-amd64/bin/javadoc \
-classpath fuseki-server.jar \ -- just a source of compiled Jena and
all dependencies
-encoding utf-8 \
-d jdoc I.java
The core problem is the form:
-
import com.hp.hpl.jena.rdf.model.Resource ;
import com.hp.hpl.jena.rdf.model.Property ;
public interface I
{
public Resource Property();
}
-
where Property is a class and a method name, which is legal, it just breaks
javadoc (standard doclet).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JENA-278) Update maven information on website
[ https://issues.apache.org/jira/browse/JENA-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson resolved JENA-278. Resolution: Fixed Patch applied published. Thank you! Update maven information on website --- Key: JENA-278 URL: https://issues.apache.org/jira/browse/JENA-278 Project: Apache Jena Issue Type: Improvement Components: Web site Reporter: Laurent Pellegrino Assignee: Ian Dickinson Labels: maven, website Attachments: maven.mdtext.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JENA-280) OntTools.nameHierarchyRoots gives wrong answer when reasoner attached
Ian Dickinson created JENA-280: -- Summary: 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: Onotology API Reporter: Ian Dickinson Assignee: Ian Dickinson See https://gist.github.com/3143188 for setup -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JENA-263) Adding resource property inside TDB transaction causes message '******* UNEXPECTED'
[ https://issues.apache.org/jira/browse/JENA-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson updated JENA-263: --- Attachment: TdbTxText.java Minimal test case to reproduce 'UNEXPECTED' error message on stdout Adding resource property inside TDB transaction causes message '*** UNEXPECTED' --- Key: JENA-263 URL: https://issues.apache.org/jira/browse/JENA-263 Project: Apache Jena Issue Type: Bug Components: TDB Affects Versions: TDB 0.9.1 Reporter: Ian Dickinson Labels: tdb Attachments: TdbTxText.java I created the attached test case while trying to isolate a problem I was seeing in some other code. This code doesn't repro the exception I'm seeing, but I do get the output ' UNEXPECTED' on stderr. Test case attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JENA-259) Add TDB classes to assembler defaults
Ian Dickinson created JENA-259: -- Summary: Add TDB classes to assembler defaults Key: JENA-259 URL: https://issues.apache.org/jira/browse/JENA-259 Project: Apache Jena Issue Type: Improvement Components: Jena Reporter: Ian Dickinson Priority: Minor Now that TDB is shipped as part of the Jena single download, it would be nice if Assemblers would recognize TDB functionality by default. At present, it's necessary to use the loadClass extension mechanism as described on http://jena.apache.org/documentation/tdb/assembler.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
