You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Joshua TAYLOR <jo...@gmail.com> on 2013/09/20 18:55:48 UTC
arq --strict incorrectly allows p{n} in property paths
According to arq --help, there's a --strict option:
--strict Operate in strict SPARQL mode (no
extensions of any kind)
However, ARQ doesn't complain about <p>{2}
$ arq --strict --data empty.n3 "select * where { ?s <p>{2} ?o }"
---------
| s | o |
=========
---------
As I read it, the working draft path language [1] allowed elt{n} (and
similar), but the SPARQL 1.1 recommendation property path syntax [2]
doesn't include them. Shouldn't arq with --strict choke on them? I
only noticed this when it came up in a StackOverflow question [3]
where a user with an old version of Jena was using such a query, and I
was trying to put together an example showing that the current
version, in strict mode, would reject it.
Unless this is intended behavior, I can open a JIRA (and maybe look
into making a patch).
//JT
[1] http://www.w3.org/TR/2010/WD-sparql11-property-paths-20100126/#path-language
[2] http://www.w3.org/TR/sparql11-query/#pp-language
[3] http://stackoverflow.com/q/18919742/1281433
--
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
Re: arq --strict incorrectly allows p{n} in property paths
Posted by Andy Seaborne <an...@apache.org>.
On 23/09/13 20:06, Joshua TAYLOR wrote:
> On Mon, Sep 23, 2013 at 2:54 PM, Andy Seaborne <an...@apache.org> wrote:
>> On 23/09/13 16:55, Joshua TAYLOR wrote:
>>>
>>> On Fri, Sep 20, 2013 at 5:12 PM, Andy Seaborne <an...@apache.org> wrote:
>>
>>
>>>> JIRA time.
>>>
>>>
>>> For anyone reading the archives, this is JENA-542:
>>>
>>> https://issues.apache.org/jira/browse/JENA-542
>>
>>
>> And it should be resolve
>>
>> (it is also JENA-537 and also JENA-538 - JIRA was overly busy over the
>> weekend, with timeouts and general confusion - eventual consistency seems to
>> rule and it's now sync'ing up)
>
> Oh, sorry for the dupes then. I didn't get around to doing this till
> a few hours ago, and I didn't see those in the recent activity. Glad
> to hear they'll be merged. Thanks!
Not your fault - the 537/538 are both me, I couldn't see them after I'd
submitted them and updates only happened eventually. The recent
activity isn't up-to-date and 538 does not show up in all views even now
(caching?). When I said JIRA was having an unusual time over the
weekend, I really did mean it!
Andy
>
>
>
Re: arq --strict incorrectly allows p{n} in property paths
Posted by Joshua TAYLOR <jo...@gmail.com>.
On Mon, Sep 23, 2013 at 2:54 PM, Andy Seaborne <an...@apache.org> wrote:
> On 23/09/13 16:55, Joshua TAYLOR wrote:
>>
>> On Fri, Sep 20, 2013 at 5:12 PM, Andy Seaborne <an...@apache.org> wrote:
>
>
>>> JIRA time.
>>
>>
>> For anyone reading the archives, this is JENA-542:
>>
>> https://issues.apache.org/jira/browse/JENA-542
>
>
> And it should be resolve
>
> (it is also JENA-537 and also JENA-538 - JIRA was overly busy over the
> weekend, with timeouts and general confusion - eventual consistency seems to
> rule and it's now sync'ing up)
Oh, sorry for the dupes then. I didn't get around to doing this till
a few hours ago, and I didn't see those in the recent activity. Glad
to hear they'll be merged. Thanks!
--
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
Re: arq --strict incorrectly allows p{n} in property paths
Posted by Andy Seaborne <an...@apache.org>.
On 23/09/13 16:55, Joshua TAYLOR wrote:
> On Fri, Sep 20, 2013 at 5:12 PM, Andy Seaborne <an...@apache.org> wrote:
>> JIRA time.
>
> For anyone reading the archives, this is JENA-542:
>
> https://issues.apache.org/jira/browse/JENA-542
And it should be resolve
(it is also JENA-537 and also JENA-538 - JIRA was overly busy over the
weekend, with timeouts and general confusion - eventual consistency
seems to rule and it's now sync'ing up)
Andy
>
>
Re: arq --strict incorrectly allows p{n} in property paths
Posted by Joshua TAYLOR <jo...@gmail.com>.
On Fri, Sep 20, 2013 at 5:12 PM, Andy Seaborne <an...@apache.org> wrote:
> On 20/09/13 18:47, Joshua TAYLOR wrote:
>>
>> On Fri, Sep 20, 2013 at 1:37 PM, Joshua TAYLOR <jo...@gmail.com>
>> wrote:
>>>>
>>>> Try the "sparql" command:
>>>>
>>>> sparql --strict --data empty.n3 "select * where { ?s <p>{2} ?o }"
>>>>
>>>> "arq" implies the extended language and "--strict" really refers to
>>>> execution semantics. "arq --strict" could be made to be (strict)
>>>> SPARQL
>>>> 1.1.
>>>
>>>
>>> sparql doesn't choke on <p>{2} either:
>>>
>>> $ sparql --data empty.n3 "select * where { ?s <p>{2} ?o }"
>>> ---------
>>> | s | o |
>>> =========
>>> ---------
>>
>>
>> I misread that, and didn't include --strict when I did it. However,
>> it doesn't reject the query with --strict, either:
>>
>> $ sparql --strict --data empty.n3 "select * where { ?s <p>{2} ?o }"
>> ---------
>> | s | o |
>> =========
>> ---------
>>
>> However, I figured out the right --syntax argument to use:
>>
>> $ sparql --syntax SPARQL_11 --data empty.n3 "select * where { ?s <p>{2} ?o
>> }"
>> Encountered " "{" "{ "" at line 1, column 24.
>
>
> Hmm - it looks like a command line string is always parsed in exended mode.
> This is not intended.
>
> Complains:
> sparql --data empty.n3 --file Q.rq
>
> Does not.
> arq --data empty.n3 --file Q.rq
> arq --data empty.n3 --file Q.arq
> sparql --data empty.n3 --file Q.arq
>
> JIRA time.
For anyone reading the archives, this is JENA-542:
https://issues.apache.org/jira/browse/JENA-542
--
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
Re: arq --strict incorrectly allows p{n} in property paths
Posted by Andy Seaborne <an...@apache.org>.
On 20/09/13 18:47, Joshua TAYLOR wrote:
> On Fri, Sep 20, 2013 at 1:37 PM, Joshua TAYLOR <jo...@gmail.com> wrote:
>>> Try the "sparql" command:
>>>
>>> sparql --strict --data empty.n3 "select * where { ?s <p>{2} ?o }"
>>>
>>> "arq" implies the extended language and "--strict" really refers to
>>> execution semantics. "arq --strict" could be made to be (strict) SPARQL
>>> 1.1.
>>
>> sparql doesn't choke on <p>{2} either:
>>
>> $ sparql --data empty.n3 "select * where { ?s <p>{2} ?o }"
>> ---------
>> | s | o |
>> =========
>> ---------
>
> I misread that, and didn't include --strict when I did it. However,
> it doesn't reject the query with --strict, either:
>
> $ sparql --strict --data empty.n3 "select * where { ?s <p>{2} ?o }"
> ---------
> | s | o |
> =========
> ---------
>
> However, I figured out the right --syntax argument to use:
>
> $ sparql --syntax SPARQL_11 --data empty.n3 "select * where { ?s <p>{2} ?o }"
> Encountered " "{" "{ "" at line 1, column 24.
Hmm - it looks like a command line string is always parsed in exended
mode. This is not intended.
Complains:
sparql --data empty.n3 --file Q.rq
Does not.
arq --data empty.n3 --file Q.rq
arq --data empty.n3 --file Q.arq
sparql --data empty.n3 --file Q.arq
JIRA time.
Andy
> …
>
> Sure enough, that works with arq, as well:
>
> $ arq --syntax SPARQL_11 --data empty.n3 "select * where { ?s <p>{2} ?o }"
> Encountered " "{" "{ "" at line 1, column 24.
> …
>
Re: arq --strict incorrectly allows p{n} in property paths
Posted by Joshua TAYLOR <jo...@gmail.com>.
On Fri, Sep 20, 2013 at 1:37 PM, Joshua TAYLOR <jo...@gmail.com> wrote:
>> Try the "sparql" command:
>>
>> sparql --strict --data empty.n3 "select * where { ?s <p>{2} ?o }"
>>
>> "arq" implies the extended language and "--strict" really refers to
>> execution semantics. "arq --strict" could be made to be (strict) SPARQL
>> 1.1.
>
> sparql doesn't choke on <p>{2} either:
>
> $ sparql --data empty.n3 "select * where { ?s <p>{2} ?o }"
> ---------
> | s | o |
> =========
> ---------
I misread that, and didn't include --strict when I did it. However,
it doesn't reject the query with --strict, either:
$ sparql --strict --data empty.n3 "select * where { ?s <p>{2} ?o }"
---------
| s | o |
=========
---------
However, I figured out the right --syntax argument to use:
$ sparql --syntax SPARQL_11 --data empty.n3 "select * where { ?s <p>{2} ?o }"
Encountered " "{" "{ "" at line 1, column 24.
…
Sure enough, that works with arq, as well:
$ arq --syntax SPARQL_11 --data empty.n3 "select * where { ?s <p>{2} ?o }"
Encountered " "{" "{ "" at line 1, column 24.
…
--
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
Re: arq --strict incorrectly allows p{n} in property paths
Posted by Joshua TAYLOR <jo...@gmail.com>.
On Fri, Sep 20, 2013 at 1:09 PM, Andy Seaborne <an...@apache.org> wrote:
> On 20/09/13 17:55, Joshua TAYLOR wrote:
>>
>> According to arq --help, there's a --strict option:
>>
>> --strict Operate in strict SPARQL mode (no
>> extensions of any kind)
>>
>> However, ARQ doesn't complain about <p>{2}
>>
>> $ arq --strict --data empty.n3 "select * where { ?s <p>{2} ?o }"
>> ---------
>> | s | o |
>> =========
>> ---------
>
>
> Try the "sparql" command:
>
> sparql --strict --data empty.n3 "select * where { ?s <p>{2} ?o }"
>
> "arq" implies the extended language and "--strict" really refers to
> execution semantics. "arq --strict" could be made to be (strict) SPARQL
> 1.1.
sparql doesn't choke on <p>{2} either:
$ sparql --data empty.n3 "select * where { ?s <p>{2} ?o }"
---------
| s | o |
=========
---------
> Actually "sparql" and "arq" are trival front ends to a command called
> "query".
Yes, I was actually digging through the source looking for valid
arguments to pass as the --syntax argument, hoping that I might be
able to specify Syntax.syntaxSPARQL_11 and get strict SPARQL 1.1
parsing. Cf. the ARQ documentation [1] which mention "These features
require the query to be parsed with an explicit declaration of
Syntax.syntaxARQ" and the Syntax class [2] which has a member
syntaxARQ. However, passing Syntax.syntaxSPARQL_11 as a syntax doesn't
work:
$ arq --syntax Syntax.syntaxSPARQL_11 --data empty.n3 "select * where
{ ?s <p>{2} ?o }"
Unrecognized syntax: Syntax.syntaxSPARQL_11
I think there's enough here for a JIRA (which I'll open up sometime
today). In the meantime, though, is there any way to get arq or
sparql to reject the query using the elt{n} syntax that didn't make it
into the SPARQL 1.1 recommendation? There do seem to be ways to make
this happen, as this question [3] on answers.semanticweb.com found
that the validator at sparql.org (correctly) rejects dc:title{2}.
//JT
[1] http://jena.apache.org/documentation/query/
[2] http://jena.apache.org/documentation/javadoc/arq/com/hp/hpl/jena/query/Syntax.html
[3] http://answers.semanticweb.com/questions/17595/sparqler-query-validator-not-up-to-date
--
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
Re: arq --strict incorrectly allows p{n} in property paths
Posted by Andy Seaborne <an...@apache.org>.
Hi Joshua,
On 20/09/13 17:55, Joshua TAYLOR wrote:
> According to arq --help, there's a --strict option:
>
> --strict Operate in strict SPARQL mode (no
> extensions of any kind)
>
> However, ARQ doesn't complain about <p>{2}
>
> $ arq --strict --data empty.n3 "select * where { ?s <p>{2} ?o }"
> ---------
> | s | o |
> =========
> ---------
Try the "sparql" command:
sparql --strict --data empty.n3 "select * where { ?s <p>{2} ?o }"
"arq" implies the extended language and "--strict" really refers to
execution semantics. "arq --strict" could be made to be (strict)
SPARQL 1.1.
Actually "sparql" and "arq" are trival front ends to a command called
"query".
> As I read it, the working draft path language [1] allowed elt{n} (and
> similar), but the SPARQL 1.1 recommendation property path syntax [2]
> doesn't include them. Shouldn't arq with --strict choke on them? I
> only noticed this when it came up in a StackOverflow question [3]
> where a user with an old version of Jena was using such a query, and I
> was trying to put together an example showing that the current
> version, in strict mode, would reject it.
>
> Unless this is intended behavior, I can open a JIRA (and maybe look
> into making a patch).
Please do if you think it's still confusing
>
> //JT
>
> [1] http://www.w3.org/TR/2010/WD-sparql11-property-paths-20100126/#path-language
> [2] http://www.w3.org/TR/sparql11-query/#pp-language
> [3] http://stackoverflow.com/q/18919742/1281433
>
Andy