Re: Definition of SPARQL variable pre-binding
Here's a slightly relevant discussion about how to support something like pre-bound variables / parametrized queries in YASQE, a graphical SPARQL editor component in the YASGUI suite (and used by Fuseki among others): https://github.com/YASGUI/YASQE/issues/24 I'm not sure I understand all the issues here very deeply, but it would seem useful to have a standard way of expressing and executing parametrized SPARQL queries, which could then be applied by YASQE and SHACL among others. -Osma On 16/06/15 12:51, Andy Seaborne wrote: On 16/06/15 09:33, Holger Knublauch wrote: Thanks, Andy. On 6/16/15 6:03 PM, Andy Seaborne wrote: On 16/06/15 04:20, Holger Knublauch wrote: Hi, (this question is motivated by the ongoing Data Shapes WG, but I don't speak on their behalf). Ptr? http://w3c.github.io/data-shapes/shacl/ esp http://w3c.github.io/data-shapes/shacl/#sparql-constraints-prebound http://www.w3.org/2014/data-shapes/track/issues/68 Thanks. Jena and other APIs such as Sesame support the concept of pre-binding variables prior to SPARQL execution, using QueryExecution.setInitialBinding(). This is convenient to reuse parameterized queries, especially with blank nodes. Question: is there any formal basis of this functionality, formulated so that it can be implemented by other platforms too? I can see that it populates the original bindings that are passed through the algebra objects, but what would be the best way to explain this by means of concepts from the SPARQL 1.1 spec? Thanks Holger There are two possible explanations - they are not quite the same. 1/ It's a substitution of a variable for a value execution. This is very like parameterized queries. It's a pre-execution step. Do you mean syntactic insertion like the ParameterizedQuery class? This would not support bnodes, and the shapes and focus nodes of a SHACL constraint will frequently be bnodes. It should also avoid repeated query parsing, for performance reasons it would be better to operate on Query objects and their general equivalents (Algebra objects). Substitution does not have to be in syntax - it's rewriting the AST with the real, actual bnode. 2/ VALUES There is a binding as a one row VALUES table and it's join'ed into the query as usual. I guess inserting a VALUES clause into the beginning would work, but then again what about bnodes? I guess instead of the VALUES keyword (as a string), it would need to rely on the equivalent algebra object? Just to be clear, this only needs to work in local datasets, not necessarily with SPARQL endpoints where all we have is a http string interface. I am looking for a couple of sentences that would provide a generic implementation strategy that most SPARQL engines either already have, or could easily add to support SHACL. Thanks Holger Firstly - I'm talking about principles and execution, not syntax. VALUES is the way to get a data table into a SPARQL execution. setInitialBinding happens after parsing - injecting the preset row into execution. The real (first) issue with blank nodes isn't putting them back in a query; it's getting them in the first place. As soon as a blank node is serialized in all W3C formats (RDF, any SPARQL results), it isn't the same blank node. There is an equivalent one in the document. If you are thinking of local API use, where the results are never serialized, then it's not an issue - like setInitialBinding, it's an API issue. setInitialBinding is working after parsing. I'm afraid that section 12.1.1 is sliding towards mixing up syntax issues with abstraction and execution. To keep to standards, you have to talk about SPARQL as a syntax. You may get away with something like ?this has the value from how you found it or SPARQL execution must ensure that ?this has a value XXX in the answers. Though XXX and blank nodes will cause the usual reactions. You and I can probably macro-generate the debate ahead of time. Perma-thread-37. The perfect answer is (might be) to repeat the pattern that found ?this in the first place. Obvious efficiency issues if done naively. But otherwise, there is no way to connect the results of one SPARQL query to another query within the standards only. [Now - may I do a 50% rules, 50% procedural language that wires together multiple SPARQL queries and updates, please?] ARQ's solution to this is _:... URIs. They name the bnode and the parser replaces them with the real blank node. In fact, RDF 1.1 says: [[ 3.4 Blank Nodes Blank nodes are disjoint from IRIs and literals. Otherwise, the set of possible blank nodes is arbitrary. RDF makes no reference to any internal structure of blank nodes. ]] so you could say, for the RDF abstract syntax, there is a 1-1 labelling of all bnodes in use (i.e. finite - none of this axion-of-choice stuff) by UUID and just be done with it. Given the UUID, you can find the blank node. Some people mix RDF abstract syntax with meaning of blank nodes (entailment) but
[jira] [Commented] (JENA-960) The construction of jena-cmd
[
https://issues.apache.org/jira/browse/JENA-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588088#comment-14588088
]
Rob Vesse commented on JENA-960:
Well speaking for Airline which I've spent a lot of time on and which I've used
for a number of both open source and proprietary projects in terms of parsing
it seems to provide most of the capabilities Jena would need:
* Ability to define options which take configurable numbers of parameters
* Ability to encapsulate related options into reusable classes
* Ability to define both long and short form options
* Ability to provide detailed built-in help
In terms of execution Airline leaves that up to the end user, there are some
standard patterns I tend to use but ultimately that is up to the implementor
Take a look at the
[examples|https://github.com/rvesse/airline/tree/master/examples/src/main/java/com/github/rvesse/airline/examples]
and see if those look like they do the kinds of things Jena needs.
For a more concrete example see
[RdfStats|https://github.com/apache/jena/blob/master/jena-elephas/jena-elephas-stats/src/main/java/org/apache/jena/hadoop/rdf/stats/RdfStats.java]
in the Elephas packages.
The construction of jena-cmd
Key: JENA-960
URL: https://issues.apache.org/jira/browse/JENA-960
Project: Apache Jena
Issue Type: Epic
Components: Jena
Reporter: A. Soroka
Priority: Minor
Labels: cli, command-line, commandline
The current machinery supporting Jena's CLI tools is too sophisticated to be
replaced entirely by off-the-shelf parts, but it is also scattered across
several modules. That's not necessary and it could be improved by
constructing a centralizing module {{jena-cmd}}. This module would depend on
SDB, TDB, and any other module that exports CLI tools as products.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] jena pull request: Lucene index synchro on triple deletion (jena-t...
Github user amiara514 commented on the pull request: https://github.com/apache/jena/pull/53#issuecomment-112409094 Yes absolutly, you can merge it... before another conflict ;-) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: [GSoC 2015 - JENA-491] Refactoring Template
On 16/06/15 12:19, Andy Seaborne wrote:
On 15/06/15 11:36, Qihong Lin wrote:
Hi,
Please check my last 3 commits[1], related to refactoring Template.
master.jj is modified accordingly, *without* implementing the new
CONSTRUCT query function for quad. Just to make sure: the maven build
test for this jena-arq module is successful.
Is there an example that I can try?
You should be able to leave the SPARQL 1.1 version of CONSTRUCT alone.
It's only the ARQ-extended form that should have your grammar. The
SPARQL 1.1 parser (like the SPARQL 1.0 parser) will be unchanged
although changes in whitespace etc in the generated java will get in the
way of seeing that.
master.jj:
#ifdef ARQ
void ConstructQuery() ; { Template t ;
QuadAcc acc = new QuadAcc() ; }
...
#else
void ConstructQuery() : { Template t ;
QuadAcc acc = new QuadAcc() ; }
This second branch should be the same bytes as the existing master.jj:
void ConstructQuery() : { Template t ;
TripleCollectorBGP acc = new
TripleCollectorBGP() ; }
{
...
You can test from the command line using the arq.qparse tool. Either
java -cp ... arq.qparse --syntax=ARQ --file=...
or
java -cp ... arq.qparse --file=Q.arq
The .arq extension will change it to ARQ syntax.
I'm looking forward to trying it out ...
Andy
Here're some ideas for to discuss:
(1) Leaving the existing methods/constructors in-place , such as new
Template(basic graph pattern), so the source code for the SPARQL 1.0
parser does not need change.
Good!
(2) Add new constructors of Template(QuadAcc qp) for future use for
the new CONSTRUCT query for quad. I use QuadAcc here (instead of
QuadPattern), because other parts of master.jj use it for parsing
quads.
That's workable but it could be a bit neater with a builder pattern like
the current Template(BGP).
The original code had TripleCollectorBGP as the builder and when it's
finished the parsing step for the CONSTRUCT template, there is a call of
getBGP() that yields the BGP. They may not be a real copy - that's an
efficiency hack, not a design issue.
Template for quads should follow the same pattern. The constructor for
Template can take ListQuad (or add getQuadPattern to QuadAcc c.f.
TripleCollectorBGP.getBGP)
(Admittedly, the existing code should also do this in other places. Code
grows organically over a long period. Consistency is unlikely!)
Why can't you use QuadPattern(QuadAcc) in ARQ-ConstructQuery?
Andy
Anything inappropriate? If it's generally OK, I'd like to continue
working on master.jj.
Great.
regards,
Qihong
[1] https://github.com/confidencesun/jena/commits/JENA-491
[jira] [Commented] (JENA-960) The construction of jena-cmd
[
https://issues.apache.org/jira/browse/JENA-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588059#comment-14588059
]
A. Soroka commented on JENA-960:
My hope is to at least replace a good portion of the CLI machinery with an
off-the-shelf part and also to rework some of the execution machinery as well.
I don't know if there are any really terrible problems with the current CLI
formats, but it's worth pointing out that this conversation started because of
JENA-959, which concerns itself with just such a question. Also, _if_
significant changes are ever to be made to the CLI machinery, isn't a major
version jump just the time to do it?
The construction of jena-cmd
Key: JENA-960
URL: https://issues.apache.org/jira/browse/JENA-960
Project: Apache Jena
Issue Type: Epic
Components: Jena
Reporter: A. Soroka
Priority: Minor
Labels: cli, command-line, commandline
The current machinery supporting Jena's CLI tools is too sophisticated to be
replaced entirely by off-the-shelf parts, but it is also scattered across
several modules. That's not necessary and it could be improved by
constructing a centralizing module {{jena-cmd}}. This module would depend on
SDB, TDB, and any other module that exports CLI tools as products.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [GSoC 2015 - JENA-491] JavaCC with master.jj
On 16/06/15 09:06, Qihong Lin wrote: Hi, Thanks! I just marked GRAPH mandatory, and it worked without producing the warnings. I'll look into the details later. By the way, if the new parser is ready, how to test it? I mean, where to drop the unit test code and the query strings to be tested? I'm confused with org.apache.jena.sparql.junit.QueryTest (is that what I need to deal with?). Any guideline or documentation for arq test? regards, Qihong Most testing of queries is by externally defined manifest files (manifest.ttl) jena-arq/testing/ARQ For now, keep it clean and start a new directory jena-arq/testing/ARQ/ConstructQuads with both syntax and execution tests. This is just to keep everything in one place for now. See jena-arq/testing/ARQ/Syntax/Syntax-ARQ/manifest.ttl and jena-arq/testing/ARQ/Construct/manifest.ttl. A manifest can have syntax and execution tests - it so happens that they are in separate places in the current test suite which was input the the working group. A syntax test looks like: :test_1 rdf:type mfx:PositiveSyntaxTestARQ ; dawgt:approval dawgt:NotClassified ; mf:namesyntax-select-expr-01.arq ; mf:action syntax-select-expr-01.arq ;. to parse syntax-select-expr-01.arq, expecting it to be good, and an execution test is an action and a result: :someExecutionTest rdf:type mfx:TestQuery ; mf:nameConstruct Quads 1 ; mf:action [ qt:query q-construct-1.rq ; qt:data data-1.ttl ] ; mf:result results-construct-1.ttl . an action is a query and a data file. There are different styles of layout in different places. The test suite has grown incrementally over the years of SPARQL 1.0 and SPARQL 1.1. Some test come from outside the project. You can test from the command line using the arq.qparse tool. See other message. There is a command qtest for running manifests. Background FYI: You won't need this when put everything in jena-arq/testing/ARQ/ConstructQuads but to explain: the main test syntax suites are auto-generated by syn.sh Part of that is syn-arq.sh. But hand writing syntax easier for now. Andy
[jira] [Commented] (JENA-960) The construction of jena-cmd
[
https://issues.apache.org/jira/browse/JENA-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588160#comment-14588160
]
A. Soroka commented on JENA-960:
There's not a dependency, but obviously, asking for a new flag raises the
question of how flags are even defined or implemented to begin with. That's how
the conversation turned to the duplication and scattered nature of the command
machinery.
The construction of jena-cmd
Key: JENA-960
URL: https://issues.apache.org/jira/browse/JENA-960
Project: Apache Jena
Issue Type: Epic
Components: Jena
Reporter: A. Soroka
Priority: Minor
Labels: cli, command-line, commandline
The current machinery supporting Jena's CLI tools is too sophisticated to be
replaced entirely by off-the-shelf parts, but it is also scattered across
several modules. That's not necessary and it could be improved by
constructing a centralizing module {{jena-cmd}}. This module would depend on
SDB, TDB, and any other module that exports CLI tools as products.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JENA-959) riot: gzip output option
[
https://issues.apache.org/jira/browse/JENA-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588216#comment-14588216
]
Andy Seaborne commented on JENA-959:
It was background on how things are as the discussion seem to be ignoring an
interaction with, e.g. {{RDFDataMgr.(read|load)}} and {{model.read}}.
riot: gzip output option
Key: JENA-959
URL: https://issues.apache.org/jira/browse/JENA-959
Project: Apache Jena
Issue Type: New Feature
Components: RIOT
Reporter: Stian Soiland-Reyes
Priority: Trivial
The riot command line tool supports incoming file formats like *.ttl.gz, but
there is no (obvious) way to also output in compressed formats.
This can of course also be achieved with piping and gzip, but that is easily
platform-specific. Writing *.format.gz with the command line is probably as
much within remit of someone using riot on the command line as for reading
those.
So my suggestion is to support extension .gz in the various --output options
to enabled outputting via a GzipOutputStream --
http://docs.oracle.com/javase/7/docs/api/java/util/zip/GZIPOutputStream.html
For example:
{code}
stain@biggie-utopic:~/Downloads$ riot --output=nquads.gz
chembl_20.0_target_targetcmpt_ls.ttl.gz
Not recognized as an RDF language : 'nquads.gz'
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JENA-961) Move arq.cmd.* to jena-base's jena.cmd
[
https://issues.apache.org/jira/browse/JENA-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588238#comment-14588238
]
A. Soroka commented on JENA-961:
I'm taking a swing at this ticket.
Move arq.cmd.* to jena-base's jena.cmd
--
Key: JENA-961
URL: https://issues.apache.org/jira/browse/JENA-961
Project: Apache Jena
Issue Type: Improvement
Components: Jena
Reporter: A. Soroka
Priority: Minor
The {{jena.cmd}} package in {{jena-base}} is a reasonable place to begin
centralizing CLI machinery and the package {{arq.cmd}} in {{jena-arq}}
contains code that could be moved there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JENA-959) riot: gzip output option
[
https://issues.apache.org/jira/browse/JENA-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588219#comment-14588219
]
Andy Seaborne commented on JENA-959:
Would it be better to assume a compositional model of pipes:
{noformat}
riot | gzip output.ttl.gz
{noformat}
especially as the user is unlikely to want compressed output going to a
terminal.
This also allows any choice of compressor (java only has a limited set
built-in).
Input files don't behave quite like output files. There are can be several on
the command line and a mix of formats and compressed/uncompressed.
riot: gzip output option
Key: JENA-959
URL: https://issues.apache.org/jira/browse/JENA-959
Project: Apache Jena
Issue Type: New Feature
Components: RIOT
Reporter: Stian Soiland-Reyes
Priority: Trivial
The riot command line tool supports incoming file formats like *.ttl.gz, but
there is no (obvious) way to also output in compressed formats.
This can of course also be achieved with piping and gzip, but that is easily
platform-specific. Writing *.format.gz with the command line is probably as
much within remit of someone using riot on the command line as for reading
those.
So my suggestion is to support extension .gz in the various --output options
to enabled outputting via a GzipOutputStream --
http://docs.oracle.com/javase/7/docs/api/java/util/zip/GZIPOutputStream.html
For example:
{code}
stain@biggie-utopic:~/Downloads$ riot --output=nquads.gz
chembl_20.0_target_targetcmpt_ls.ttl.gz
Not recognized as an RDF language : 'nquads.gz'
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JENA-959) riot: gzip output option
[
https://issues.apache.org/jira/browse/JENA-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588245#comment-14588245
]
A. Soroka commented on JENA-959:
I guess the question then is whether [~stain]'s use case is likely to be
popular. if it is, then some kind of pattern would be nice. If not, then maybe
the solution really doesn't warrant changes in Jena.
riot: gzip output option
Key: JENA-959
URL: https://issues.apache.org/jira/browse/JENA-959
Project: Apache Jena
Issue Type: New Feature
Components: RIOT
Reporter: Stian Soiland-Reyes
Priority: Trivial
The riot command line tool supports incoming file formats like *.ttl.gz, but
there is no (obvious) way to also output in compressed formats.
This can of course also be achieved with piping and gzip, but that is easily
platform-specific. Writing *.format.gz with the command line is probably as
much within remit of someone using riot on the command line as for reading
those.
So my suggestion is to support extension .gz in the various --output options
to enabled outputting via a GzipOutputStream --
http://docs.oracle.com/javase/7/docs/api/java/util/zip/GZIPOutputStream.html
For example:
{code}
stain@biggie-utopic:~/Downloads$ riot --output=nquads.gz
chembl_20.0_target_targetcmpt_ls.ttl.gz
Not recognized as an RDF language : 'nquads.gz'
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JENA-959) riot: gzip output option
[
https://issues.apache.org/jira/browse/JENA-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588151#comment-14588151
]
Andy Seaborne commented on JENA-959:
To pipe a gziped stream: {{-}} is the standard input.
{noformat}
gzip -d | riot --syntax TTL -- -
{noformat}
riot: gzip output option
Key: JENA-959
URL: https://issues.apache.org/jira/browse/JENA-959
Project: Apache Jena
Issue Type: New Feature
Components: RIOT
Reporter: Stian Soiland-Reyes
Priority: Trivial
The riot command line tool supports incoming file formats like *.ttl.gz, but
there is no (obvious) way to also output in compressed formats.
This can of course also be achieved with piping and gzip, but that is easily
platform-specific. Writing *.format.gz with the command line is probably as
much within remit of someone using riot on the command line as for reading
those.
So my suggestion is to support extension .gz in the various --output options
to enabled outputting via a GzipOutputStream --
http://docs.oracle.com/javase/7/docs/api/java/util/zip/GZIPOutputStream.html
For example:
{code}
stain@biggie-utopic:~/Downloads$ riot --output=nquads.gz
chembl_20.0_target_targetcmpt_ls.ttl.gz
Not recognized as an RDF language : 'nquads.gz'
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JENA-960) The construction of jena-cmd
[
https://issues.apache.org/jira/browse/JENA-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588160#comment-14588160
]
A. Soroka edited comment on JENA-960 at 6/16/15 3:22 PM:
-
There's not a dependency, but obviously, asking for a new flag raises the
question of how flags are even defined or implemented to begin with. That's how
the conversation turned to the duplication in and scattered nature of the
command machinery.
was (Author: ajs6f):
There's not a dependency, but obviously, asking for a new flag raises the
question of how flags are even defined or implemented to begin with. That's how
the conversation turned to the duplication and scattered nature of the command
machinery.
The construction of jena-cmd
Key: JENA-960
URL: https://issues.apache.org/jira/browse/JENA-960
Project: Apache Jena
Issue Type: Epic
Components: Jena
Reporter: A. Soroka
Priority: Minor
Labels: cli, command-line, commandline
The current machinery supporting Jena's CLI tools is too sophisticated to be
replaced entirely by off-the-shelf parts, but it is also scattered across
several modules. That's not necessary and it could be improved by
constructing a centralizing module {{jena-cmd}}. This module would depend on
SDB, TDB, and any other module that exports CLI tools as products.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JENA-961) Move arq.cmd.* to jena-base's jena.cmd
[
https://issues.apache.org/jira/browse/JENA-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588485#comment-14588485
]
ASF GitHub Bot commented on JENA-961:
-
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/77
Move arq.cmd.* to jena-base's jena.cmd
https://issues.apache.org/jira/browse/JENA-961
This is a multi-module PR, but I could find no other way to do it: since
several Jena modules depend on `jena-arq` for their command-processing, moving
machinery from `jena-arq` to `jena-base` caused changes in them. However, those
are minor changes (e.g. changes in imports) and the meat of the PR is where it
should be, in `jena-arq` and `jena-base`.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ajs6f/jena JENA-961
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/jena/pull/77.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #77
commit 87e07fb4d7277099642eb15e8f3973d965678e29
Author: ajs6f aj...@virginia.edu
Date: 2015-06-16T16:13:15Z
Removing jena-arq/arq.cmd in favor of jena-base/jena.cmd
commit dccc406223ddcd71835163d301f7c51ad2d94bd9
Author: ajs6f aj...@virginia.edu
Date: 2015-06-16T16:45:13Z
Reusing jena-base/jena.cmd classes in jena-core
commit 883cb89d3fd1b8383c2b033ef9e214efcf262aa6
Author: ajs6f aj...@virginia.edu
Date: 2015-06-16T17:50:54Z
Cleanup after moving command framework
Move arq.cmd.* to jena-base's jena.cmd
--
Key: JENA-961
URL: https://issues.apache.org/jira/browse/JENA-961
Project: Apache Jena
Issue Type: Improvement
Components: Jena
Reporter: A. Soroka
Priority: Minor
The {{jena.cmd}} package in {{jena-base}} is a reasonable place to begin
centralizing CLI machinery and the package {{arq.cmd}} in {{jena-arq}}
contains code that could be moved there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JENA-961) Move arq.cmd.* to jena-base's jena.cmd
[
https://issues.apache.org/jira/browse/JENA-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588486#comment-14588486
]
A. Soroka commented on JENA-961:
https://github.com/apache/jena/pull/77
Move arq.cmd.* to jena-base's jena.cmd
--
Key: JENA-961
URL: https://issues.apache.org/jira/browse/JENA-961
Project: Apache Jena
Issue Type: Improvement
Components: Jena
Reporter: A. Soroka
Priority: Minor
The {{jena.cmd}} package in {{jena-base}} is a reasonable place to begin
centralizing CLI machinery and the package {{arq.cmd}} in {{jena-arq}}
contains code that could be moved there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] jena pull request: Move arq.cmd.* to jena-base's jena.cmd
GitHub user ajs6f opened a pull request: https://github.com/apache/jena/pull/77 Move arq.cmd.* to jena-base's jena.cmd https://issues.apache.org/jira/browse/JENA-961 This is a multi-module PR, but I could find no other way to do it: since several Jena modules depend on `jena-arq` for their command-processing, moving machinery from `jena-arq` to `jena-base` caused changes in them. However, those are minor changes (e.g. changes in imports) and the meat of the PR is where it should be, in `jena-arq` and `jena-base`. You can merge this pull request into a Git repository by running: $ git pull https://github.com/ajs6f/jena JENA-961 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/jena/pull/77.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #77 commit 87e07fb4d7277099642eb15e8f3973d965678e29 Author: ajs6f aj...@virginia.edu Date: 2015-06-16T16:13:15Z Removing jena-arq/arq.cmd in favor of jena-base/jena.cmd commit dccc406223ddcd71835163d301f7c51ad2d94bd9 Author: ajs6f aj...@virginia.edu Date: 2015-06-16T16:45:13Z Reusing jena-base/jena.cmd classes in jena-core commit 883cb89d3fd1b8383c2b033ef9e214efcf262aa6 Author: ajs6f aj...@virginia.edu Date: 2015-06-16T17:50:54Z Cleanup after moving command framework --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (JENA-966) LazyIterator
Claude Warren created JENA-966:
--
Summary: LazyIterator
Key: JENA-966
URL: https://issues.apache.org/jira/browse/JENA-966
Project: Apache Jena
Issue Type: Bug
Components: Core
Affects Versions: Jena 3.0.0
Reporter: Claude Warren
Assignee: Claude Warren
LazyIterator is an abstract class. The documentation indicates that the
create() method needs to be overridden to create an instance. From this I
would expect that
now LazyIterator(){
@Override
public ExtendedIteratorModel create() {
...
}};
Would work however LazyIterator does not override:
remoteNext(), andThen(), toList(), and toSet().
I believe these should be implemented in the class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] jena pull request: Lucene index synchro on triple deletion (jena-t...
Github user afs commented on the pull request: https://github.com/apache/jena/pull/53#issuecomment-112564393 Ack! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] jena pull request: Move arq.cmd.* to jena-base's jena.cmd
Github user afs commented on the pull request: https://github.com/apache/jena/pull/77#issuecomment-112548845 Moving into jena-base is probably the best first step. It separates it from gathering all the commands which may well not be good idea anyway, or at least, a pointless exercise that risks breaking people's scripts (that may not use the provided ones, or have installed copies). --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Definition of SPARQL variable pre-binding
On 6/16/2015 22:03, Osma Suominen wrote:
Here's a slightly relevant discussion about how to support something
like pre-bound variables / parametrized queries in YASQE, a graphical
SPARQL editor component in the YASGUI suite (and used by Fuseki among
others): https://github.com/YASGUI/YASQE/issues/24
Thanks for the pointer.
I'm not sure I understand all the issues here very deeply, but it
would seem useful to have a standard way of expressing and executing
parametrized SPARQL queries, which could then be applied by YASQE and
SHACL among others.
Indeed. Maybe the SHACL templates [1] could be one solution to that,
assuming SHACL becomes a W3C standard. In the current draft you would
specify a template as
ex:MyTemplate
a sh:Template ;
rdfs:label My template ;
rdfs:comment Gets a list of all people born in a given country ;
sh:argument [
sh:predicate ex:country ;
sh:valueType schema:Country ;
rdfs:comment The country to get all people for ;
] ;
sh:sparql
SELECT ?person
WHERE {
?person ex:bornIn ?country .
} ;
.
This structure provides enough metadata to drive user interfaces, e.g.
input forms where users select a country from a list. The semantics in
the current draft are that variables become pre-bound (ex:country -
?country). This approach has the advantage that each query can be
instantiated as a naturally valid RDF instance, e.g.
ex:ExampleQuery
a ex:MyTemplate ;
ex:country ex:Germany .
This can then be used as a high level language for all kinds of query
calls as constraints, rules or whatever - experts can prepare the SPARQL
while end users just fill in the blanks.
The semantics are intended to be like inserting a VALUES clause into the
beginning of the query, i.e. they wouldn't be visible in sub-selects
etc. In contrast to text-substitution algorithms, this also makes sure
that queries are always syntactically valid and can be pre-compiled.
Holger
[1] http://w3c.github.io/data-shapes/shacl/#templates
-Osma
On 16/06/15 12:51, Andy Seaborne wrote:
On 16/06/15 09:33, Holger Knublauch wrote:
Thanks, Andy.
On 6/16/15 6:03 PM, Andy Seaborne wrote:
On 16/06/15 04:20, Holger Knublauch wrote:
Hi,
(this question is motivated by the ongoing Data Shapes WG, but I
don't
speak on their behalf).
Ptr?
http://w3c.github.io/data-shapes/shacl/
esp http://w3c.github.io/data-shapes/shacl/#sparql-constraints-prebound
http://www.w3.org/2014/data-shapes/track/issues/68
Thanks.
Jena and other APIs such as Sesame support the concept of pre-binding
variables prior to SPARQL execution, using
QueryExecution.setInitialBinding(). This is convenient to reuse
parameterized queries, especially with blank nodes.
Question: is there any formal basis of this functionality,
formulated so
that it can be implemented by other platforms too? I can see that it
populates the original bindings that are passed through the algebra
objects, but what would be the best way to explain this by means of
concepts from the SPARQL 1.1 spec?
Thanks
Holger
There are two possible explanations - they are not quite the same.
1/ It's a substitution of a variable for a value execution. This is
very like parameterized queries. It's a pre-execution step.
Do you mean syntactic insertion like the ParameterizedQuery class? This
would not support bnodes, and the shapes and focus nodes of a SHACL
constraint will frequently be bnodes. It should also avoid repeated
query parsing, for performance reasons it would be better to operate on
Query objects and their general equivalents (Algebra objects).
Substitution does not have to be in syntax - it's rewriting the AST with
the real, actual bnode.
2/ VALUES
There is a binding as a one row VALUES table and it's join'ed into the
query as usual.
I guess inserting a VALUES clause into the beginning would work, but
then again what about bnodes? I guess instead of the VALUES keyword (as
a string), it would need to rely on the equivalent algebra object?
Just to be clear, this only needs to work in local datasets, not
necessarily with SPARQL endpoints where all we have is a http string
interface. I am looking for a couple of sentences that would provide a
generic implementation strategy that most SPARQL engines either already
have, or could easily add to support SHACL.
Thanks
Holger
Firstly - I'm talking about principles and execution, not syntax. VALUES
is the way to get a data table into a SPARQL execution.
setInitialBinding happens after parsing - injecting the preset row into
execution.
The real (first) issue with blank nodes isn't putting them back in a
query; it's getting them in the first place.
As soon as a blank node is serialized in all W3C formats (RDF, any
SPARQL results), it isn't the same blank node. There is an equivalent
one in the document.
If you are thinking of local API use, where the results are never
serialized, then it's not an issue
[jira] [Created] (JENA-964) remove home argument from fuseki startup script
Yang Yuanzhe created JENA-964: - Summary: remove home argument from fuseki startup script Key: JENA-964 URL: https://issues.apache.org/jira/browse/JENA-964 Project: Apache Jena Issue Type: Bug Components: Fuseki Affects Versions: Fuseki 2.0.0, Fuseki 2.0.1 Reporter: Yang Yuanzhe Hi Andy, How is everything going? Today I tried to run fuseki as a service with the provided script fuseki. However it gave me an error Unknown argument: home. Then inside the script I found ### if [ ! -z $FUSEKI_HOME ] then FUSEKI_ADDITIONAL_ARGS=(--home $FUSEKI_HOME) fi ### However, since fuseki 2.0.0, --home has been removed. I guess we need to do corresponding adaptions. Thank you very much and have a nice day. Regards, Yang -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [GSoC 2015 - JENA-491] JavaCC with master.jj
Hi,
Thanks! I just marked GRAPH mandatory, and it worked without
producing the warnings. I'll look into the details later.
By the way, if the new parser is ready, how to test it? I mean, where
to drop the unit test code and the query strings to be tested? I'm
confused with org.apache.jena.sparql.junit.QueryTest (is that what I
need to deal with?). Any guideline or documentation for arq test?
regards,
Qihong
On Mon, Jun 15, 2015 at 11:45 PM, Ying Jiang jpz6311...@gmail.com wrote:
Hi Qihong,
In addition to Andy's explanation, You might take look at this
tutorial for more details on javacc lookahead:
https://javacc.java.net/doc/lookahead.html
Best regards,
Ying Jiang
On Mon, Jun 15, 2015 at 10:42 PM, Andy Seaborne a...@apache.org wrote:
Qihong,
There is an ambiguity in the grammar if you make GRAPH optional.
See rule 'Quads'
Consider these two cases:
:s :p :o .
:z { :s1 :p1 :o1 } .
:s :p :o .
:z :q :o2 .
when the parser get to end of the triple in the default graph:
:s :p :o .
there are two ways forward: more triples (TriplesTemplate) and end of the
triples part, start of named graph.
It looks ahead one token and see :z and needs to decide whether the next
rule is more triples, the :z :q :o2 . case, or the end of the triples for
the default graph and the start of a named graph the :z { :s1 :p1 :o1 } .
where it exists TriplesTemplate and moves on to QuadsNotTriples
If GRAPH then the entry to QuadsNotTriples is marked by a GRAPH which is
never in triples.
The grammar is LL(1) - a lookahead of 1 - by default.
There are two solutions (I haven't checked exact deatils):
1/ Use LOOKAHEAD(2) so it sees tokens ':z' and ':q' or ':z' (triples) and
'{' which is the named graphs case. I think this is in Quads somewhere.
2/ Leave GRAPH required.
(2) is fine for now - it will not be too unexpected to users because INSERT
DATA requires a GRAPH and it is legal TriG, even if not the short form in
TriG.
You can come back and look at (1) later. I'm keen for you to get something
going as soon as possible, not get lost in details.
Background:
There is a third solution but it's not as so simple which is to introduce an
intermediate state of MaybeTriplesMaybeQuads but if you do that, more of
the grammar needs rewriting. I'm not sure how widespread the changes would
be.
Jena's TriG parser (which is not JavaCC based see
LangTriG::oneNamedGraphBlock2)
has this comment:
// Either :s :p :o or :g { ... }
and does one look ahead to get the :s or :g (the :z above), keeps that
hanging around, does another lookahead to see '{' or not, then calls
turtle(n) if triples.
In LangTriG:
turtle() is roughly TriplesSameSubject
turtle(n) is roughly PropertyListNotEmpty
Andy
On 15/06/15 11:53, Qihong Lin wrote:
Hi,
I'm trying to play with master.jj. But the grammar script somethings
prints warning messages. The behavior is strange. In order to simplify
my question, I'd like to take the following example:
In QuadsNotTriples(), line 691 in master.jj, in the master branch:
GRAPH
If I change it to optional (which is required in future
implementations, for the new grammar):
(GRAPH)?
the grammar script goes like this:
$ ./grammar
Process grammar -- sparql_11.jj
Java Compiler Compiler Version 5.0 (Parser Generator)
(type javacc with no arguments for help)
Reading from file sparql_11.jj . . .
Warning: Choice conflict in [...] construct at line 464, column 4.
Expansion nested within construct and expansion following
construct
have common prefixes, one of which is: VAR1
Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in [...] construct at line 468, column 6.
Expansion nested within construct and expansion following
construct
have common prefixes, one of which is: VAR1
Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in [...] construct at line 484, column 12.
Expansion nested within construct and expansion following
construct
have common prefixes, one of which is: VAR1
Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in [...] construct at line 759, column 3.
Expansion nested within construct and expansion following
construct
have common prefixes, one of which is: VAR1
Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in [...] construct at line 767, column 5.
Expansion nested within construct and expansion following
construct
have common prefixes, one of which is: VAR1
Consider using a lookahead of 2 or more for nested expansion.
File TokenMgrError.java does not exist. Will create one.
File ParseException.java does not exist. Will create one.
File
Re: Definition of SPARQL variable pre-binding
Thanks, Andy. On 6/16/15 6:03 PM, Andy Seaborne wrote: On 16/06/15 04:20, Holger Knublauch wrote: Hi, (this question is motivated by the ongoing Data Shapes WG, but I don't speak on their behalf). Ptr? http://w3c.github.io/data-shapes/shacl/ esp http://w3c.github.io/data-shapes/shacl/#sparql-constraints-prebound http://www.w3.org/2014/data-shapes/track/issues/68 Jena and other APIs such as Sesame support the concept of pre-binding variables prior to SPARQL execution, using QueryExecution.setInitialBinding(). This is convenient to reuse parameterized queries, especially with blank nodes. Question: is there any formal basis of this functionality, formulated so that it can be implemented by other platforms too? I can see that it populates the original bindings that are passed through the algebra objects, but what would be the best way to explain this by means of concepts from the SPARQL 1.1 spec? Thanks Holger There are two possible explanations - they are not quite the same. 1/ It's a substitution of a variable for a value execution. This is very like parameterized queries. It's a pre-execution step. Do you mean syntactic insertion like the ParameterizedQuery class? This would not support bnodes, and the shapes and focus nodes of a SHACL constraint will frequently be bnodes. It should also avoid repeated query parsing, for performance reasons it would be better to operate on Query objects and their general equivalents (Algebra objects). 2/ VALUES There is a binding as a one row VALUES table and it's join'ed into the query as usual. I guess inserting a VALUES clause into the beginning would work, but then again what about bnodes? I guess instead of the VALUES keyword (as a string), it would need to rely on the equivalent algebra object? Just to be clear, this only needs to work in local datasets, not necessarily with SPARQL endpoints where all we have is a http string interface. I am looking for a couple of sentences that would provide a generic implementation strategy that most SPARQL engines either already have, or could easily add to support SHACL. Thanks Holger Differences in these viewpoints can occur in nested patetrns - sub-queries (you can have different variables with the same name - a textual substitution viewpoint breaks that) and OPTIONALs inside OPTIONALs (bottom up execution is not the same as top down execution). This has existed in ARQ for a very long time. ARQ actually takes the initial binding and seeds the execution from there so it's like (2) but not exactly; it does respect non-projected variables inside nested SELECTS; it does not complete respect certain cases of OPTIONAL-inside-OPTIONAL. Andy
Re: Trouble Building Under Eclipse
Just got back from holiday Have gone through the rest of the thread on this and it seems like just having jena-base closed in Eclipse does resolve the issue for me Rob On 05/06/2015 16:04, Andy Seaborne a...@apache.org wrote: Rob, Did you get this sorted? Any clues? Andy On 04/06/15 14:51, Andy Seaborne wrote: Rob, I've not had problems recently but some time ago I got similar. In fact, I get it for other dependencies as well and it seems ot be come down to variation between Eclipse and the maven local repo. Once, they got quite out of step and I deleted and did mvn dependency:resolve (I tend to use the command line). My current practice is not to have jena-base as an open project in Eclipse. Andy On 04/06/15 14:30, aj...@virginia.edu wrote: I have had this problem since I began tinkering. The only solution I have found is make sure that the jena-shaded-guava project is never open when any project that refers to types therein is open. This isn't much of a burden, and I suppose it has something to do with the Maven magic that is going on inside jena-shaded-guava. I'm not totally clear as to why Jena shades Guava into its own namespace-- is it to avoid OSGi-exporting Guava packages? (We have something like that going on in another project on which I work.) --- A. Soroka The University of Virginia Library On Jun 4, 2015, at 9:22 AM, Rob Vesse rve...@dotnetrdf.org wrote: Folks Recently I've been having a lot of trouble getting Jena to build in Eclipse which seems to be due to the use of the Shade plugin to Shade Guava. Any module that has a reference to the shaded classes ends refuses to build with various variations of the following error: java.lang.NoClassDefFoundError: org/apache/jena/ext/com/google/common/cache/RemovalNotification Anybody else been having this issue? If so how did you resolve it? Sometimes cleaning my workspace and/or doing a mvn package at the command line seems to help but other times it doesn't Rob
[jira] [Commented] (JENA-965) Threading Issue in OntDocumentManager.loadImports
[ https://issues.apache.org/jira/browse/JENA-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14587845#comment-14587845 ] Andy Seaborne commented on JENA-965: Failed to reproduce on Ubuntu (Jena 2.13.0 and Jena 3.0.0 development). Threading Issue in OntDocumentManager.loadImports - Key: JENA-965 URL: https://issues.apache.org/jira/browse/JENA-965 Project: Apache Jena Issue Type: Bug Components: Ontology API Reporter: Andy Seaborne Report: http://mail-archives.apache.org/mod_mbox/jena-dev/201506.mbox/%3C6F0B5BA9CFA66949BE5140A145108BD443E2C72A%40ALPMBAPA01.e2k.ad.ge.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JENA-965) Threading Issue in OntDocumentManager.loadImports
Andy Seaborne created JENA-965: -- Summary: Threading Issue in OntDocumentManager.loadImports Key: JENA-965 URL: https://issues.apache.org/jira/browse/JENA-965 Project: Apache Jena Issue Type: Bug Components: Ontology API Reporter: Andy Seaborne Report: http://mail-archives.apache.org/mod_mbox/jena-dev/201506.mbox/%3C6F0B5BA9CFA66949BE5140A145108BD443E2C72A%40ALPMBAPA01.e2k.ad.ge.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Definition of SPARQL variable pre-binding
On 16/06/15 04:20, Holger Knublauch wrote: Hi, (this question is motivated by the ongoing Data Shapes WG, but I don't speak on their behalf). Ptr? Jena and other APIs such as Sesame support the concept of pre-binding variables prior to SPARQL execution, using QueryExecution.setInitialBinding(). This is convenient to reuse parameterized queries, especially with blank nodes. Question: is there any formal basis of this functionality, formulated so that it can be implemented by other platforms too? I can see that it populates the original bindings that are passed through the algebra objects, but what would be the best way to explain this by means of concepts from the SPARQL 1.1 spec? Thanks Holger There are two possible explanations - they are not quite the same. 1/ It's a substitution of a variable for a value execution. This is very like parameterized queries. It's a pre-execution step. 2/ VALUES There is a binding as a one row VALUES table and it's join'ed into the query as usual. Differences in these viewpoints can occur in nested patetrns - sub-queries (you can have different variables with the same name - a textual substitution viewpoint breaks that) and OPTIONALs inside OPTIONALs (bottom up execution is not the same as top down execution). This has existed in ARQ for a very long time. ARQ actually takes the initial binding and seeds the execution from there so it's like (2) but not exactly; it does respect non-projected variables inside nested SELECTS; it does not complete respect certain cases of OPTIONAL-inside-OPTIONAL. Andy
[jira] [Commented] (JENA-960) The construction of jena-cmd
[
https://issues.apache.org/jira/browse/JENA-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14587739#comment-14587739
]
Rob Vesse commented on JENA-960:
In the long term is the thought that we might move off to an alternative
framework?
There was some discussion on the list that I didn't quite follow that Commons
CLI was missing some functionality that Jena would need. Can you expand on
that?
Would something like [Airline|http://github.com/rvesse/airline] be a suitable
choice, I already used it for the Elephas demo application
The construction of jena-cmd
Key: JENA-960
URL: https://issues.apache.org/jira/browse/JENA-960
Project: Apache Jena
Issue Type: Epic
Components: Jena
Reporter: A. Soroka
Priority: Minor
Labels: cli, command-line, commandline
The current machinery supporting Jena's CLI tools is too sophisticated to be
replaced entirely by off-the-shelf parts, but it is also scattered across
several modules. That's not necessary and it could be improved by
constructing a centralizing module {{jena-cmd}}. This module would depend on
SDB, TDB, and any other module that exports CLI tools as products.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Definition of SPARQL variable pre-binding
On 16/06/15 09:33, Holger Knublauch wrote: Thanks, Andy. On 6/16/15 6:03 PM, Andy Seaborne wrote: On 16/06/15 04:20, Holger Knublauch wrote: Hi, (this question is motivated by the ongoing Data Shapes WG, but I don't speak on their behalf). Ptr? http://w3c.github.io/data-shapes/shacl/ esp http://w3c.github.io/data-shapes/shacl/#sparql-constraints-prebound http://www.w3.org/2014/data-shapes/track/issues/68 Thanks. Jena and other APIs such as Sesame support the concept of pre-binding variables prior to SPARQL execution, using QueryExecution.setInitialBinding(). This is convenient to reuse parameterized queries, especially with blank nodes. Question: is there any formal basis of this functionality, formulated so that it can be implemented by other platforms too? I can see that it populates the original bindings that are passed through the algebra objects, but what would be the best way to explain this by means of concepts from the SPARQL 1.1 spec? Thanks Holger There are two possible explanations - they are not quite the same. 1/ It's a substitution of a variable for a value execution. This is very like parameterized queries. It's a pre-execution step. Do you mean syntactic insertion like the ParameterizedQuery class? This would not support bnodes, and the shapes and focus nodes of a SHACL constraint will frequently be bnodes. It should also avoid repeated query parsing, for performance reasons it would be better to operate on Query objects and their general equivalents (Algebra objects). Substitution does not have to be in syntax - it's rewriting the AST with the real, actual bnode. 2/ VALUES There is a binding as a one row VALUES table and it's join'ed into the query as usual. I guess inserting a VALUES clause into the beginning would work, but then again what about bnodes? I guess instead of the VALUES keyword (as a string), it would need to rely on the equivalent algebra object? Just to be clear, this only needs to work in local datasets, not necessarily with SPARQL endpoints where all we have is a http string interface. I am looking for a couple of sentences that would provide a generic implementation strategy that most SPARQL engines either already have, or could easily add to support SHACL. Thanks Holger Firstly - I'm talking about principles and execution, not syntax. VALUES is the way to get a data table into a SPARQL execution. setInitialBinding happens after parsing - injecting the preset row into execution. The real (first) issue with blank nodes isn't putting them back in a query; it's getting them in the first place. As soon as a blank node is serialized in all W3C formats (RDF, any SPARQL results), it isn't the same blank node. There is an equivalent one in the document. If you are thinking of local API use, where the results are never serialized, then it's not an issue - like setInitialBinding, it's an API issue. setInitialBinding is working after parsing. I'm afraid that section 12.1.1 is sliding towards mixing up syntax issues with abstraction and execution. To keep to standards, you have to talk about SPARQL as a syntax. You may get away with something like ?this has the value from how you found it or SPARQL execution must ensure that ?this has a value XXX in the answers. Though XXX and blank nodes will cause the usual reactions. You and I can probably macro-generate the debate ahead of time. Perma-thread-37. The perfect answer is (might be) to repeat the pattern that found ?this in the first place. Obvious efficiency issues if done naively. But otherwise, there is no way to connect the results of one SPARQL query to another query within the standards only. [Now - may I do a 50% rules, 50% procedural language that wires together multiple SPARQL queries and updates, please?] ARQ's solution to this is _:... URIs. They name the bnode and the parser replaces them with the real blank node. In fact, RDF 1.1 says: [[ 3.4 Blank Nodes Blank nodes are disjoint from IRIs and literals. Otherwise, the set of possible blank nodes is arbitrary. RDF makes no reference to any internal structure of blank nodes. ]] so you could say, for the RDF abstract syntax, there is a 1-1 labelling of all bnodes in use (i.e. finite - none of this axion-of-choice stuff) by UUID and just be done with it. Given the UUID, you can find the blank node. Some people mix RDF abstract syntax with meaning of blank nodes (entailment) but they are different. abstract syntax == data structure. As a data structure, blank nodes are just nodes in a graph. So invent a reference for them (not a URI, not a literal). Every RDF systems does anyway even if it is implicitly there like a java object reference (not Jena - blank nodes are the same by .equals, not ==; usual java stuff here). Andy Differences in these viewpoints can occur in nested patetrns - sub-queries (you can have different variables with the same name - a textual
[jira] [Commented] (JENA-960) The construction of jena-cmd
[
https://issues.apache.org/jira/browse/JENA-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14587807#comment-14587807
]
Andy Seaborne commented on JENA-960:
Unclear. jena command line processing isn't just parsing the command line,
it's the way commands execute.
If the command line parsing changes, for all proposals, the critical point is
how does it affect the user? What will visibly change? Is that good or bad?
The construction of jena-cmd
Key: JENA-960
URL: https://issues.apache.org/jira/browse/JENA-960
Project: Apache Jena
Issue Type: Epic
Components: Jena
Reporter: A. Soroka
Priority: Minor
Labels: cli, command-line, commandline
The current machinery supporting Jena's CLI tools is too sophisticated to be
replaced entirely by off-the-shelf parts, but it is also scattered across
several modules. That's not necessary and it could be improved by
constructing a centralizing module {{jena-cmd}}. This module would depend on
SDB, TDB, and any other module that exports CLI tools as products.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JENA-964) remove home argument from fuseki startup script
[
https://issues.apache.org/jira/browse/JENA-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne resolved JENA-964.
Resolution: Fixed
Fix Version/s: Fuseki 2.0.1
Thanks for that. Now fixed in the codebase.
remove home argument from fuseki startup script
-
Key: JENA-964
URL: https://issues.apache.org/jira/browse/JENA-964
Project: Apache Jena
Issue Type: Bug
Components: Fuseki
Affects Versions: Fuseki 2.0.0
Reporter: Yang Yuanzhe
Assignee: Andy Seaborne
Priority: Minor
Fix For: Fuseki 2.0.1
Hi Andy,
How is everything going?
Today I tried to run fuseki as a service with the provided script fuseki.
However it gave me an error Unknown argument: home. Then inside the script
I found
{noformat}
if [ ! -z $FUSEKI_HOME ]
then
FUSEKI_ADDITIONAL_ARGS=(--home $FUSEKI_HOME)
fi
{noformat}
However, since fuseki 2.0.0, --home has been removed. I guess we need to do
corresponding adaptions.
Thank you very much and have a nice day.
Regards,
Yang
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (JENA-964) remove home argument from fuseki startup script
[
https://issues.apache.org/jira/browse/JENA-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne reassigned JENA-964:
--
Assignee: Andy Seaborne
remove home argument from fuseki startup script
-
Key: JENA-964
URL: https://issues.apache.org/jira/browse/JENA-964
Project: Apache Jena
Issue Type: Bug
Components: Fuseki
Affects Versions: Fuseki 2.0.0
Reporter: Yang Yuanzhe
Assignee: Andy Seaborne
Priority: Minor
Hi Andy,
How is everything going?
Today I tried to run fuseki as a service with the provided script fuseki.
However it gave me an error Unknown argument: home. Then inside the script
I found
{noformat}
if [ ! -z $FUSEKI_HOME ]
then
FUSEKI_ADDITIONAL_ARGS=(--home $FUSEKI_HOME)
fi
{noformat}
However, since fuseki 2.0.0, --home has been removed. I guess we need to do
corresponding adaptions.
Thank you very much and have a nice day.
Regards,
Yang
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JENA-964) remove home argument from fuseki startup script
[
https://issues.apache.org/jira/browse/JENA-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne updated JENA-964:
---
Priority: Minor (was: Major)
remove home argument from fuseki startup script
-
Key: JENA-964
URL: https://issues.apache.org/jira/browse/JENA-964
Project: Apache Jena
Issue Type: Bug
Components: Fuseki
Affects Versions: Fuseki 2.0.0
Reporter: Yang Yuanzhe
Priority: Minor
Hi Andy,
How is everything going?
Today I tried to run fuseki as a service with the provided script fuseki.
However it gave me an error Unknown argument: home. Then inside the script
I found
{noformat}
if [ ! -z $FUSEKI_HOME ]
then
FUSEKI_ADDITIONAL_ARGS=(--home $FUSEKI_HOME)
fi
{noformat}
However, since fuseki 2.0.0, --home has been removed. I guess we need to do
corresponding adaptions.
Thank you very much and have a nice day.
Regards,
Yang
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JENA-964) remove home argument from fuseki startup script
[
https://issues.apache.org/jira/browse/JENA-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne updated JENA-964:
---
Affects Version/s: (was: Fuseki 2.0.1)
remove home argument from fuseki startup script
-
Key: JENA-964
URL: https://issues.apache.org/jira/browse/JENA-964
Project: Apache Jena
Issue Type: Bug
Components: Fuseki
Affects Versions: Fuseki 2.0.0
Reporter: Yang Yuanzhe
Hi Andy,
How is everything going?
Today I tried to run fuseki as a service with the provided script fuseki.
However it gave me an error Unknown argument: home. Then inside the script
I found
{noformat}
if [ ! -z $FUSEKI_HOME ]
then
FUSEKI_ADDITIONAL_ARGS=(--home $FUSEKI_HOME)
fi
{noformat}
However, since fuseki 2.0.0, --home has been removed. I guess we need to do
corresponding adaptions.
Thank you very much and have a nice day.
Regards,
Yang
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JENA-964) remove home argument from fuseki startup script
[
https://issues.apache.org/jira/browse/JENA-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne updated JENA-964:
---
Description:
Hi Andy,
How is everything going?
Today I tried to run fuseki as a service with the provided script fuseki.
However it gave me an error Unknown argument: home. Then inside the script I
found
{noformat}
if [ ! -z $FUSEKI_HOME ]
then
FUSEKI_ADDITIONAL_ARGS=(--home $FUSEKI_HOME)
fi
{noformat}
However, since fuseki 2.0.0, --home has been removed. I guess we need to do
corresponding adaptions.
Thank you very much and have a nice day.
Regards,
Yang
was:
Hi Andy,
How is everything going?
Today I tried to run fuseki as a service with the provided script fuseki.
However it gave me an error Unknown argument: home. Then inside the script I
found
###
if [ ! -z $FUSEKI_HOME ]
then
FUSEKI_ADDITIONAL_ARGS=(--home $FUSEKI_HOME)
fi
###
However, since fuseki 2.0.0, --home has been removed. I guess we need to do
corresponding adaptions.
Thank you very much and have a nice day.
Regards,
Yang
remove home argument from fuseki startup script
-
Key: JENA-964
URL: https://issues.apache.org/jira/browse/JENA-964
Project: Apache Jena
Issue Type: Bug
Components: Fuseki
Affects Versions: Fuseki 2.0.0, Fuseki 2.0.1
Reporter: Yang Yuanzhe
Hi Andy,
How is everything going?
Today I tried to run fuseki as a service with the provided script fuseki.
However it gave me an error Unknown argument: home. Then inside the script
I found
{noformat}
if [ ! -z $FUSEKI_HOME ]
then
FUSEKI_ADDITIONAL_ARGS=(--home $FUSEKI_HOME)
fi
{noformat}
However, since fuseki 2.0.0, --home has been removed. I guess we need to do
corresponding adaptions.
Thank you very much and have a nice day.
Regards,
Yang
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JENA-964) remove home argument from fuseki startup script
[
https://issues.apache.org/jira/browse/JENA-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14587815#comment-14587815
]
ASF subversion and git services commented on JENA-964:
--
Commit 7040f19e208c93235f072c129940990751379d97 in jena's branch
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=7040f19 ]
JENA-964: Remove --home flag (not used in Fuseki2)
remove home argument from fuseki startup script
-
Key: JENA-964
URL: https://issues.apache.org/jira/browse/JENA-964
Project: Apache Jena
Issue Type: Bug
Components: Fuseki
Affects Versions: Fuseki 2.0.0
Reporter: Yang Yuanzhe
Hi Andy,
How is everything going?
Today I tried to run fuseki as a service with the provided script fuseki.
However it gave me an error Unknown argument: home. Then inside the script
I found
{noformat}
if [ ! -z $FUSEKI_HOME ]
then
FUSEKI_ADDITIONAL_ARGS=(--home $FUSEKI_HOME)
fi
{noformat}
However, since fuseki 2.0.0, --home has been removed. I guess we need to do
corresponding adaptions.
Thank you very much and have a nice day.
Regards,
Yang
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [GSoC 2015 - JENA-491] Refactoring Template
On 15/06/15 11:36, Qihong Lin wrote: Hi, Please check my last 3 commits[1], related to refactoring Template. master.jj is modified accordingly, *without* implementing the new CONSTRUCT query function for quad. Just to make sure: the maven build test for this jena-arq module is successful. Here're some ideas for to discuss: (1) Leaving the existing methods/constructors in-place , such as new Template(basic graph pattern), so the source code for the SPARQL 1.0 parser does not need change. Good! (2) Add new constructors of Template(QuadAcc qp) for future use for the new CONSTRUCT query for quad. I use QuadAcc here (instead of QuadPattern), because other parts of master.jj use it for parsing quads. That's workable but it could be a bit neater with a builder pattern like the current Template(BGP). The original code had TripleCollectorBGP as the builder and when it's finished the parsing step for the CONSTRUCT template, there is a call of getBGP() that yields the BGP. They may not be a real copy - that's an efficiency hack, not a design issue. Template for quads should follow the same pattern. The constructor for Template can take ListQuad (or add getQuadPattern to QuadAcc c.f. TripleCollectorBGP.getBGP) (Admittedly, the existing code should also do this in other places. Code grows organically over a long period. Consistency is unlikely!) Why can't you use QuadPattern(QuadAcc) in ARQ-ConstructQuery? Andy Anything inappropriate? If it's generally OK, I'd like to continue working on master.jj. Great. regards, Qihong [1] https://github.com/confidencesun/jena/commits/JENA-491
