path statements in queries

[Claude Warren <cl...@xenei.com>]

I know that the SPARQL recommendation states that path elements must be URIs
(https://www.w3.org/TR/sparql11-property-paths/#id41857)

but sine the path may be expanded as noted in the recommendation so that
{noformat}

     {
            ?x foaf:mbox <ma...@example> .
            ?x foaf:knows/foaf:knows/foaf:name ?name .
     }

{noformat}

This is the same as the strict SPARQL query:
{noformat}

     {
            ?x foaf:mbox <ma...@example> .
            ?x foaf:knows [  foaf:knows [ foaf:name ?name ]] .
     }

{noformat}

Would it not make sense that variables could be used in the path? So that

{noformat}

     {
            ?x foaf:mbox <ma...@example> .
            ?x foaf:knows/?var/foaf:name ?name .
     }

{noformat}

This is the same as the strict SPARQL query:
{noformat}

     {
            ?x foaf:mbox <ma...@example> .
            ?x foaf:knows [  ?var [ foaf:name ?name ]] .
     }

{noformat}

The query builder could handle this case -- actually currently the query
builder handles this case incorrectly as it will build the path with the
var and ARQ will execute it correctly.

Is there a reason not to suggest this change to W3C?  Does anyone know if
it has been discussed before?

Claude
-- 
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren

Re: path statements in queries

[Andy Seaborne <an...@apache.org>]

On 27/06/17 10:54, Claude Warren wrote:
> I know that the SPARQL recommendation states that path elements must be URIs
> (https://www.w3.org/TR/sparql11-property-paths/#id41857)
> 
> but sine the path may be expanded as noted in the recommendation so that

This optimization already exists in ARQ. TransformPathFlattern callign 
PathFlattern.

> {noformat}
> 
>       {
>              ?x foaf:mbox <ma...@example> .
>              ?x foaf:knows/foaf:knows/foaf:name ?name .
>       }
> 
> {noformat}
> 
> This is the same as the strict SPARQL query:
> {noformat}
> 
>       {
>              ?x foaf:mbox <ma...@example> .
>              ?x foaf:knows [  foaf:knows [ foaf:name ?name ]] .
>       }
> 
> {noformat}
> 
> Would it not make sense that variables could be used in the path? 

"Paths" includes ?x*, ^?x and path expressions (:p|?x)*

> So that
> 
> {noformat}
> 
>       {
>              ?x foaf:mbox <ma...@example> .
>              ?x foaf:knows/?var/foaf:name ?name .
>       }
> 
> {noformat}
> 
> This is the same as the strict SPARQL query:
> {noformat}
> 
>       {
>              ?x foaf:mbox <ma...@example> .
>              ?x foaf:knows [  ?var [ foaf:name ?name ]] .
>       }
> 
> {noformat}
> 
> The query builder could handle this case -- actually currently the query
> builder handles this case incorrectly as it will build the path with the
> var and ARQ will execute it correctly.

ARQ will not execute paths with variables.

If it executes, it's because PathFlatten turned it into a non-path. 
This is out-of-contract so it is luck ("GIGO")

> 
> Is there a reason not to suggest this change to W3C? 

What benefit does it have? It only works for things that can be written 
another way .... so write it the way that exists.

(BTW It does not work for higher level of entailment.)

Being able to build queries that can be used remotely with other stores 
is very important.

> Does anyone know if
> it has been discussed before?

Yes.

The real need is path values.

	Andy

> 
> Claude
>