Re: Slice semantics, and rdf:first and rdf:rest considered harmful Re: Updated LD Patch specification

On Wed, Nov 26, 2014 at 8:03 PM, Alexandre Bertails <alexandre@bertails.org>
wrote:

> On Wed, Nov 26, 2014 at 1:44 PM, Tim Berners-Lee <timbl@w3.org> wrote:
> >
> > 1) I think the whole reification of arrays as rdf:first and rdf:rest
> pairs
> > is one of th things which makes RDF look weird to people.    Can you
> explain
> > it in terms or an RDF Collection as an array/list of things just leaving
> out
> > the first and rest stuff? You can put that in an appendix maybe.
>
> You mean like how Python would do that for example?
>
> That is an interesting remark, as the semantics here is explained in
> term of first/rest, but it doesn't say that rdf:List have to be
> implemented that way. So yes, we can explain that, maybe directly in
> <#update-list-statement>.
>

I also think that makes sense.

>
> > 2) On of the nice things about js and  python is that the slice function
> > a[x.:y]   aka  a.slice(x,y) is actually consistent between the two
> > languages! So useful. Let's leverage that developer knowledge
>
> Indeed. The inspiration was never hidden :-)
>
> >
> > No need to be different from that i.e. instead of:
> >
> > 2..4 denotes the slice ( "dolor" "sit" )
> > 3.. denotes the slice ( "sit" "amet" )
> > 2..2 denotes the empty slice located between "ipsum" and "dolor"
> > .. denotes the empty slice located at the end of the list
> >
> > say
> >
> > 2..4 denotes the slice ( "dolor" "sit" )
> > 3.. denotes the slice ( "sit" "amet" )
> > 2..2 denotes the empty slice located between "ipsum" and "dolor"
> > .. denotes the entire list
>
> Pierre-Antoine, Andrei, and I had discussed about that a lot. There is
> no convention in Python (we think) to speak about the end of the list,
> so that you can easily append to it using this syntax.


That's indeed why we introduced that syntax -- although I just realized
there **is** a way to append a list in Python using slices :
>>> lst = [ 10, 20, 30]
>>> lst[3:3] = [40, 50]
>>> lst
[10, 20, 30, 40, 50]

I didn't know you could use indexes >= len(lst), but in a way that makes
sense. Note however that you have to know the length of the list, while the
".." syntax in LD Patch makes it possible to extend a list regardless of
its length.


> That is why we
> went with `..`. Note that you can always denote the entire list with
> `0..`, which is what LD Patch does, and that is consistent with
> Python.
>

Actually, it is not consistent with Python, because in Python lst[:] does
denote the entire list. So that's why Tim is suggesting this change, I
guess. At the time, I thought it was an acceptable divergence, because 1/
it could still be expressed as 0.. (which is consistent with Python), and
2/ I didn't know any other way to address the end of the list.


> > -2 .. denotes  the last two       "sit" "amen"
> > -2 .. -2  denotes the one starting at  the second and ending 2 from the
> end
> > "dolor"
>
> We had also thought about it. The main difference is that with
> negative indexes, the Patch engine would need to know where the end of
> the list is, or know its size.
>
> That being said, the context is Linked Data, where the resources
> shouldn't be too big anyway, especially the lists. So that might not
> be an issue. I will also bring the discussion to the group.
>

It would still make it a little harder to implement UpdateList, but indeed
it should not cause a huge performance problem in our context...


> Alexandre
>
> >
> >
> >
> > Tim
> >
> > On 2014-11 -21, at 17:13, Alexandre Bertails <alexandre@bertails.org>
> wrote:
> >
> > All,
> >
> > We have updated the LD Patch specification [1].
> >
> > We may have few fixes over the week-end, but we believe it is now
> > stable and ready for review. You can find a summary of the changes at
> > the end of the document.
> >
> > Most notably:
> >
> > * this includes TimBL's proposal to accept Turtle in Add statements.
> > * ISSUE-100 is *pro-actively resolved*, please see [2]
> > *  we believe that comments from TimBL, Steve, and Sandro are addressed.
> >
> > Cheers,
> >
> > Alexandre
> >
> > [1] https://dvcs.w3.org/hg/ldpwg/raw-file/ldpatch/ldpatch.html
> > [2] http://lists.w3.org/Archives/Public/public-ldp-wg/2014Nov/0064.html
> >
> >
>
>