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

On 13 Nov 2012, at 19:19, Roger Menday <roger.menday@uk.fujitsu.com> wrote:

> 
> 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 ... :)

You don't need to deploy all the resoning engine behind this. 

My argument was in two stages:

 1. show you how you can see that a form is equivalent to a SPARQL ask query
 2. todo: find out how one can do that with what is currently standardised - sparql forms
   seem to me to be very useful pretty much everywhere.
 3. the develop a simple vocab for size of answer results and sections of results
    and from there every page could just send a sparql form with such a query allowing the user
    to select which parts of the answer space he wanted to get to.

So if one solves 2 - it may be simple - we have the answer to quite a lot of other problems. I have 
found the need for some way of giving semantics to forms a number of other places. If you think
about how popular html forms are then it should be obvioous that sparql forms would be very very
helpful too...

Henry

> 
> 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.
>> 
> 

Social Web Architect
http://bblfish.net/