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

hi Henry, 

>>> I think you don't understand my point. I am not saying that one should
>>> use an RDF backend. I am saying that semantically those two queries are
>>> identical. One is readable by a human agent, an agent that can add very
>>> sophisticated contextual information to read a page in order to determine
>>> the semantics, the other is readable by robots which don't then need to
>>> learn how to add  context to the statements.
>> 
>> 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. 
> It is also a template of a question. If you look at my example
> 
> 
> <FORM action="http://somesite.com/prog/adduser" method="post">
>   <P>
>   First name: <INPUT type="text" name="firstname"><BR>
>   Last name: <INPUT type="text" name="lastname"><BR>
>   email: <INPUT type="text" name="email"><BR>
>   <INPUT type="radio" name="sex" value="Male"> Male<BR>
>   <INPUT type="radio" name="sex" value="Female"> Female<BR>
>   <BUTTON name="submit" value="submit" type="submit">
>   Send<IMG src="/icons/wow.gif" alt="wow"></BUTTON>
>   <BUTTON name="reset" type="reset">
>   Reset<IMG src="/icons/oops.gif" alt="oops"></BUTTON>
>   </P>
> </FORM>
> 
> 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.

Far-out!! i'm used to a "user" sending a SPARQL query to a server which then processes it, and you are saying that the "user" takes on the role of a SPARQL engine. But, I can really see how this can be used as a sophisticated form language. 

> 
>> maybe the form contents
>> are used for a query into something, maybe they are used to generate a new
>> resource from the form model, or maybe the form contents simply drive a
>> business process that doesn't easily translate to a read or write
>> operation on any database at all. the only thing that actually matters for
>> a form is the fact that it a way to capture "model-driven information"
>> from a client, and get it to a server. a form is state passed from server
>> to client, a filled out form is state passed from client to server driven
>> by the form.
> 
> 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 an example of forms being used to direct the application (as in issue-26), going beyond the case where the type of the request entity is the same of the resource which is eventually created. 

>> 
>> since a form is simply a template a client is asked to populate, the
>> question is what model you have for that. HTML, for example, has created
>> its own simple model of a few form controls, and then most of the
>> capabilities lie in the fact that a publisher can freely arrange those
>> form controls in a form using HTML layout/labels and form field names.
>> thanks to scripting, these can even magically change at fill-out time and
>> for example generate new fields on the fly, when human users fill in
>> repeating fields and need more repeating fields.
> 
> Those are UI models, not semantic models. They don't make the context clear.
> This works for humans, not for robots.
> 
>> 
>> where things get a bit more complicated is in the overall model of the
>> form. for example, when a field is repeating, and you have scripting to
>> generate new entries on the fly, the "model" is actually encoded in
>> scripting, so there's no machine-understandable way for clients to
>> understand how many repeating entries they can generate. XForms attempted
>> to change that and uses an approach where the "form model" is explicitly
>> communicated between the server and the client (in this case in XML). this
>> worked great, only that the release of XForms unfortunately came around
>> the same time as XML became uncool, and because of this (and some other
>> reasons as well) adoption was more limited than initially hoped for.
>> however, XForms are still used for a variety of applications, because of
>> their ability to clearly express the form model.
> 
> I wonder how close this would be to an RDF notion of a model. XML is a syntax.
> What we in the LDP working group would like is something that works nicely with
> the semantic reasoning tools we have.

Actually, wrt uptake of our standard, I think what the LDP working group needs is something that does *NOT* require the semantic reasoning tools that we have ... :)

Roger

> 
>> 
>> 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.
> 
>> however, i'd say that doing this is outside of the
>> scope of the WG, and all we can hope for is to use existing specs.
> 
> SPARQL already exists :-)
> 
>> URI
>> Templates are different from XForms in that the model is much simpler that
>> XML or RDF; it's just a bunch of name/value pairs (with a couple of twists
>> such as repeating values and more, depending on the level
>> http://tools.ietf.org/html/rfc6570#section-1.2). but maybe that's better
>> than nothing and good enough to drive some of the things we'd like to do.
> 
> yes, RDF just provides semantics on top of these things. 
> 
>> 
>>> By adding semantics to forms, you end up discovering that a web form
>>> is just equivalent to a query - but where the user is the agent answering.
>> 
>> i think your understanding of forms is limited here. forms do much more
>> than drive queries, and a form itself is nothing but a model template
>> that's made available by a server, so that a client can complete it
>> according to constraints, and then submit an instance of form data to the
>> server. driving some query is an important subset of form use cases, but
>> not all there is.
> 
> I think that is because you don't see that a query can guide action.
> Say the policemen who stops you on the street asks you "have you drunk
> more than four glasses of red wine in the last hour?" Whatever you answer
> will have consequences quite clearly, way beyond the direct meaning of the
> answer you give.
>