Re: Comments on Linked Data Patch Format FWPD

On 2014-09 -26, at 17:06, Pierre-Antoine Champin <pchampin@liris.cnrs.fr> wrote:
> 
> Correct. Also, in SPARQL Upadte, an INSERT may have no effect (if its variables are not bound), and the next one could still have an effect. In LD-Patch, if a Bind ?x fails, every Add (including those not involving ?x) will fail -- actually, the whole patch will. So being to similar to SPARQL may break expectations.

Well, changing the WHERE to REQUIRE or  ForOne or as you have it Bind I think makes that clear -- the system will never do an INSERT or a DELETE with unbound variables as there won't be any (or the patch will fail).

> 
> > 7) Maybe :: or some thing as a index operator, not just a space.   The conventional [] are overused already, of course.
> 
> Can you please clarify? I am not sure to understand what you mean.
> Maybe an example?
> 
> It might have to do with our misunderstanding on 3).
> Currently, if I want to match the location of the third author, I have to write
> 
>   Bind ?loc <#doc>/v:authors/2/v:location .


I suppose I am looking at this syntax and and wondering about how it would fit in with other languages like turtle, sparql, n3, n4 in future, etc.

	 <#doc>/v:authors 

I understand because its semantics seem to be the same as N3's

	 <#doc>!v:authors
or
	 <#doc> ! v:authors

or
	[ is v:authors of <#doc> ]


and 

	<#doc>/^foaf:made

I understand because it seems to have the same semantics of N3's

	<#doc>^foaf:made
or
	<#doc> ^ foaf:made

which  turtle does not include and writes as

	[ foaf:made <#doc> ]

which seems happy.

(By the way, if you haven't come across it an exhaustive explanation of consideration for N3's path syntax are in http://www.w3.org/DesignIssues/N3Alternatives.  )

and then I'm looking at the 

	<#authorlist> / 2

and it seems to overload the / arc operator as an array index operator.
In N3 that would be 

	<#authorList> ! 2

What makes me a bit queasy?  I feel the operation in different, and you are using the 
following number syntax to disambiguate it.  Which is a it of a kludge.

I'm thinking how do I parse 

	<#authorList> / ?y


(even though LDPatch doesn't actually allow that other languages derived from it could.)


So if this were Python we would write

	<#theauthorlist> [ 2 ]

but we can't as the square brackets are totally used up already in turtle.   Hence the thought of :: 

so what I was thinking as if we invented a new operator  say :: but whatever then it could be fairly useful in other places.

     <#docs> / <#authorlist> :: 2  / v:location

Tim

PS: An alternative I suppose which is bold and would probably produce a large amount of discussion on many lists would be to say that in fact we were in fact following a path arc, and that 2 is actually an rdf Predicate which links an array and its second (or third) entry. I could imagine adding that to the rule engine..but it would cause so much fuss that we would never get anything finished.
But it would justify the same operator in the path syntax.




> 
> So there are '/', not just spaces...
> What is it exactly you suggest? Something like:
> 
>   Bind ?loc <#doc>/v:authors::2/v:location .
> 
> I'm not sure I see the value of a different separator. As explained in the spec, you can think of integers (in the Step production rules) as syntactic sugar for the corresponding sequence of rdf:rest and rdf:first, as the path above is equivalent to

(I hope no one has to think in terms of rdf:rest !)

>   Bind ?loc <#doc>/v:authors/  rdf:rest/rdf:rest/rdf:first  /v:location .
> 
> hence the choice to use the same separator for IRIs and integers.

I see where it came from now. like /rdf:rest*2/
I don't  normally think in terms of rdf:rest.

> 
>  best
> 
> 
> Cheers,
> 
> Alexandre
> 
> >
> > My 2¢ worth anyway
> >
> > Tim
> >
> > Developer hat on
> > Director hat off
> >
> >
> >
> >
>