Re: ldp-ISSUE-33 (pagination): how to structure functionality

Where we get back to the topic of pagination, with an example...

On 13 Nov 2012, at 22:19, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:

> hello henry.
> 
>>> let's look at this in a very plain way: a form is nothing but a template
>>> that clients are expected to fill out and return.
>> yes, it is a query to the user. The user is answering a question.
> 
> not "a context-free question", but a question that is heavily
> contextualized through the service context the client is going through.
> 
>> This is asking the user for his firstname, last name, email and sex.
>> This could also have been written as
>> SELECT ?firstname, ?lastname, ?email, ?sex
>> WHERE {
>> <http://you.org/#me> foaf:fname ?firstname;
>>           foaf:givenName ?lastname;
>>           foaf:mbox ?email;
>>           foaf:gender ?sex .
>> }
>> you will see that it is a template because the user can only fill in the
>> answers for the ?firstname, ?lastname, ?email and ?sex variables. The user
>> is not asking the question but answering a template.
> 
> ok, now let's assume for a minute that i have a couple thousand contacts,
> and i do in fact manage them client-side as an RDF store (which is quite
> an assumption to make). now let's also assume that i, as the client, am
> willing to run server-supplied queries against my data, which raises all
> kinds of interesting security and privacy issues, but let's even ignore
> those for a moment. how would that query select the one contact info i
> actually want to submit for the single interaction where i am presented
> with this form? i don't need a detailed answer here, but i have a hard
> time envisioning how this could even remotely function.

This is getting off topic. But let me answer quickly
 1. the query is not asking for anybody's name, but for the name of the person
    authenticated: in the example this was <http://you.org/#me> . So you don't 
    need a huge address book. the server is asking for your name, just as it was 
    in the html form.
 2. of course the client would also need access control rules on what can be shown. 
    But why does that seem so difficult to imagine? We need them on the server. 
    Clients and servers are interchangeable. They are jsut roles played in a 
    communication flow: The web is peer to peer.

Let us get back on the topic of pagination. The following html form would do 
as a simple pagination form for a collection <> .  

<FORM action="p?" method="post">
 <P>
 page number:  <INPUT type="text" name="page"><BR>
 entries per page: <INPUT type="text" name="pageSz"><BR>
 <BUTTON name="Get answers" value="submit" type="submit"></BUTTON>
</FORM> 

Are you with me here?

So let's transform the above form into a SPARQL query

SELECT ?page ?pageSz 
TO <p>
WHERE {
  [] a PaginationSlice;
     :pageNumber ?page;
     :entriesPerPage ?pageSz .
}

Good so we have a query that is put forward to the user/robot, as one he can answer 
in order to get a pagination slice. In a usual sparql query the endpoint is 
known and the agent can ask whatever query he likes. But here we are imagining 
that the resource can specify the endpoint, and what answers can be sent to 
that resource. So we need to specify where TO send the answers of course :-) 

Btw. this is much easier to program server side than a SPARQL query
end point. In fact it is just as easy to program as a normal html form: you 
don't  need to set up a full blown SPARQL query engine on the other side,
all you need to do is deal with ?page and ?pageSz as you would have done in
a form.

Perhaps we would need to specify what POSTing that answer to TO does. Perhaps that
is as easy as adding 

<p> a pagination:view;
    pagination:for <> ;
    pagination:query """
           SELECT ?page ?pageSz 
           TO <p>
           WHERE {
              [] a PaginationSlice;
                 :pageNumber ?page;
                 :entriesPerPage ?pageSz .
            }
    """^^sprlq:SelectQuery .

This is of course just a first quick sketch off the top of my head.
I am sure one can do a lot better with some input and enthusiasm from the folks
here assembled.



> 
>> The form asks the user a question. What the server then does with the
>> answer
>> depends on the form. Say the form asks:
>> "Do you want to buy 1 book entitled 'Hitch Hikers Guide to the Galaxy'?"
>> And the user presses "yes", then the user has answered the question. But
>> of course
>> he has also made one more step towards buying the book.
> 
> this is template-driven and works: the server presents a template ("do you
> want to confirm order xyz", answer yes/no), and the client instantiates it
> based on client intent. this is not what you present above as the server
> querying into a client-side data model. how would this here translate to
> your model?

well you just work a yes no query. That could be an ASK query for example.

> 
>> Those are UI models, not semantic models. They don't make the context
>> clear.
>> This works for humans, not for robots.
> 
> these are service models, not UI models. you need to understand the book
> ordering service to understand what it means to select "yes/no" from the
> "yes/no" question, right?

Later when we have worked out the details we can get the RDFa people to work out 
some how to markup a real form neatly and beautifully so that the html form and the
query can be nicely merged together... For the moment I am just describing the
general idea. We can leave UI for later, when the model is clear, and work with 
psychologists to find out what people find most natural.

> 
>>> if your goal is to build an RDF-centric version of XForms, then you can
>>> do
>>> that and XForms would be a useful thing to look at and see what worked
>>> well, and what didn't.
>> yes. But not just XForms. SPARQL is a form language already. So it would
>> be interesting to see what is missing.
> 
> how is SPARQL a form language? it is a query language.

Because a form is just a query to the user! 

> 
> cheers,
> 
> dret.
> 

Social Web Architect
http://bblfish.net/