Re: LD Patch comments/questions

Hi Gregg,

On Fri, Aug 14, 2015 at 3:56 AM, Gregg Kellogg <gregg@greggkellogg.net>
wrote:

> I’ve been attempting an implementation in Ruby [1], and came up with some
> observations and questions:
>
> # Bind
>
> These examples are of more complicated binds which are syntactically
> correct. The test suite could probably use more pathological examples.
>

Where does this list come from? Is it a generalization of all the Bind
statements found in the test suite? If so, I think at least one example is
missing:  spec_example24_positive.ldpatch contains a variable in the path.
But surely, more pathologogical examples could be added.

>
>         Bind ?x :a / :b / :c
>         Bind ?x :a / ^:b / :c
>         Bind ?x :a [ / :p = "v"] / :c / ^:d
>         Bind ?x :a / 1 / :b
>         Bind ?x :a / [ / :c / :d = "bar"] / ^:e
>         Bind ?x :a / ! / ^:e
>

The last example is incorrect: "!" should not be preceded by "/".
Additionally, although ":a" is syntactically correct, I'm guessing what you
mean is "?a", so it should read

    Bind ?x ?a ! / ^:e

Note that the "!" here is not very interesting since, if ?a is bound, it
must be bound to a unique value -- and if it is not bound, this is an
error, see below.

What is the effect of a bind statement using unbound variables (as values)?
>

Per the last list item of 4.3.8 Error Handling
<http://www.w3.org/TR/ldpatch/#error-handling>, If a variable is used
without being previously bound, then the parsing fails . This applies to
*any* statement.

You should not think of variable as "logical variables", as in SPARQL, but
rather as "program variables" (i.e. placeholders containing a value, a node
of the graph) that are required as an indirection to refer to blank nodes.

>
> A unicity constraint ("!") at the end of a path seems redundant, but might
> be used within a path.
>

That is correct.

>
> The above Bind statements might be equivalent to the following SPARQL
> queries.
>
>         SELECT ?x WHERE {:a :b / :c ?x}
>         SELECT ?x WHERE {:a ^:b / :c ?x }
>         SELECT ?x WHERE {:a :p "v"; :c / ^:d ?x }
>         SELECT ?x WHERE {:a rdf:rest _:0 . _:0 rdf:first _:1 . _:1 :b ?x}
>         SELECT ?x WHERE {:a :c/:d "bar"; ^:e ?x}
>         SELECT ?x WHERE {?a ^:e ?x} GROUP BY ?a HAVING(COUNT(?a) = 1)
>
> where each query must have exactly one single result.
>

Correct, except for the last one, which is not valid SPARQL (according to
the SPARQL validator <http://sparql.org/query-validator.html>).
(?x can not be selected directly, as it is not part of the GROUP BY)

Let us consider a more regular use of "!"

  Bind ?x :a / :b ! / :c

I would translate it that way:

  SELECT ?x WHERE {
    { SELECT ?v1 { :a :b ?v1 } HAVING (COUNT(?v1) = 1) }
    ?v1 :c ?x
  }

where the query must have exactly one single result.

Note also that the 4th query could be simpler:

  SELECT ?x WHERE { :a rdf:rest / rdf:first / :b ?x }


> Compiling such queries is non-trivial; any thought about an informative
> section on turning Bind statements into SPARQL queries? For this to work
> with indexes would require a hypothetical extension to SPARQL introducing
> some INDEX-like extension to property-paths.
>

We have not considered that, but it could indeed be valuable for people
implementing LD-Patch on top of a SPARQL engine. I don't think that an
extension to SPARQL is required, considering that numeric indexes can be
considered as syntactic sugar for property paths of the form

   rdf:rest / rdf:rest / rdf:rest ... / rdf:first

Granted, unicity constraints are trickier to handle in the general case
(especially when they appear berween square brackets), but I think a
systematic translation process can be devised...


# Add
> Can a graph contain unbound variables?
>

No, same answer as with Bind above.


> Are they treated just like BNodes?
> Do such variables create bindings for subsequent usage?
>
> # Delete
> Same for add, can a delete graph contain unbound variables? Is this an
> error?
>

Same answer :)

>
> # Cut
> Can the argument of Cut be an IRI? Doc indicates it's a BNode, or variable
> binding to a BNode.
> Is it an error to attempt to cut an unbound variable?
>

Yes, for the same reason as above: *any* use of an unbound variable is an
error.

 best


> Gregg Kellogg
> gregg@greggkellogg.net
>
> [1]
> https://github.com/gkellogg/ld-patch/tree/feature/initial-implementation
>
>
>