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

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

> hello henry.
> 
> i'll refrain from further emails after this one unless others think this
> conversation is useful.

yes, it would be nice to hear from the SPARQL and RDF folks what they make 
of this proposal next.

> 
>> 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?
> 
> this is the service surface and if you used standardized link relations,
> no form is required an RFC5005 would happily guide all interactions. let's
> assume you don't want this. if your service documented what the field
> names mean, then this would be a proper service.
> 
>> So let's transform the above form into a SPARQL query
>> SELECT ?page ?pageSz
>> TO <p>
>> WHERE {
>> [] a PaginationSlice;
>>    :pageNumber ?page;
>>    :entriesPerPage ?pageSz .
>> }
> 
> you cannot "transform a form into a SPARQL query." a form is a template
> that defines what kind of input a service expects.

What else is a question? It is a way for a questioner to ask the questionee
to fill in a template.

Joe asks Jim "How old are you?" is the same as 
Joe telling Jim "Jim is x years old." please fill in x for this sentence to make 
a true sentence. Here the template is given by the above partial sentence where 
the questionee has to fill in the x variable to make a true sentence.

SPARQL is a templating language if you want. When you ask the server a question
you are asking it to fill in a template to return you all the true results. Since
being a client or a server is just a role one plays it is completely possible
to have a server ask a client a question.


> clients are expected to
> fill out the template, taking into account all constraints that are
> defined as part of the service.

just as in the question about age above.

> servers validate the data, and if the
> request validates the pre-conditions, it is executed.

That would be no different from an answer to the age question. If the
returned answer does not give a number as an age, the answer does not
validate.

> this can mean that
> (part of the) form data is used to populate a query. it can also drive
> code that has no query component to it whatsoever, and simply computes the
> service's response.

As I pointed out we can drive pagination using a system like this. You
can really do anything you can do with forms this way. It's just that you
make it much clearer what you are doing. As a result we don't need to invent
a different protocol for every service need we come up with. All we need
to do is come agree on a vocabulary for different use cases. That is the
RDF way of doing things.

> 
>>>> 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.
> 
> personally speaking, for the immediate WG goals, there's too much "and
> yes, we need to fill in all those blank spots" in here. all i have been
> trying to do is explaining how REST approaches this problem, and how
> existing standards could be used to prevent us from reinventing some
> wheels.

My proposal is completely RESTful. 
Furthermore I am not re-invent anything, I am just making the semantics
explicit for what these other standards are already doing. It should
be easy to GRDDL those other formats into this proposal.

> 
>>>> 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!
> 
> a form is a template with a service-defined model.

A SPARQL query is a template of a graph pattern. Add a description 
of what the answer ill do and you get your resource model.

> a query languages
> queries any kind of data that's managed based on some general-purpose
> metamodel.

That is when you leave the query open. But when a particular query 
is asked, and if you limit yourself to only a particular query, then
you are just doing forms.


> these are different things. you might have visions of how forms
> and/or query languages could be changed or designed to completely change
> how things are currently working, but going back to ISSUE-33, the question
> was how to expose pagination affordances in a more general way, and web
> architecture and existing standards give us a pretty solid starting point.

I am basing myself on web architecture, existing standards, and even
if you want works on the theory of language and speech acts. But that 
would bring us a bit further afield.

> 
> cheers,
> 
> dret.
> 

Social Web Architect
http://bblfish.net/