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

On 13 Nov 2012, at 18:30, "Wilde, Erik" <> wrote:

> hello henry.
> On 2012-11-13 1:37 , "Henry Story" <> wrote:
>> 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="" method="post">
   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>

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

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

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

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

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

> cheers,
> dret.

Social Web Architect

Received on Tuesday, 13 November 2012 17:42:34 UTC