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

hello henry.

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

not "a context-free question", but a question that is heavily
contextualized through the service context the client is going through.

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

ok, now let's assume for a minute that i have a couple thousand contacts,
and i do in fact manage them client-side as an RDF store (which is quite
an assumption to make). now let's also assume that i, as the client, am
willing to run server-supplied queries against my data, which raises all
kinds of interesting security and privacy issues, but let's even ignore
those for a moment. how would that query select the one contact info i
actually want to submit for the single interaction where i am presented
with this form? i don't need a detailed answer here, but i have a hard
time envisioning how this could even remotely function.

>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 template-driven and works: the server presents a template ("do you
want to confirm order xyz", answer yes/no), and the client instantiates it
based on client intent. this is not what you present above as the server
querying into a client-side data model. how would this here translate to
your model?

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

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

how is SPARQL a form language? it is a query language.

cheers,

dret.

Received on Tuesday, 13 November 2012 21:20:23 UTC