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

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

> 
> On 13 Nov 2012, at 18:25, Henry Story wrote:
> 
>> 
>> 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
> 
> why is an ASK query ? i though that only requires boolean answers, i.e. not enough in this case (?)

Oops sorry. I meant a SELECT 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/
>> 
> 

Social Web Architect
http://bblfish.net/