W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

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

From: Henry Story <henry.story@bblfish.net>
Date: Tue, 13 Nov 2012 10:37:26 +0100
Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>
Message-Id: <348908AA-A74C-4AAC-B4F3-73B0FC534DB2@bblfish.net>
To: "Wilde, Erik" <Erik.Wilde@emc.com>

On 13 Nov 2012, at 01:47, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:

> hello henry.
> 
> On 2012-11-12 13:33 , "Henry Story" <henry.story@bblfish.net> wrote:
>> It is part of a GET form, not of a POST form.
> 
> that depends entirely on how your media type decides to use POST forms.
> you can go both ways, and both ways are fine.
> 
>>> the crucial
>>> difference to a generic query language is a that a form exposes a
>>> service-specific way of what clients can ask for, and then on the
>>> service
>>> side can be translated into whatever actual query language the backend
>>> happens to use.
>> Forms are just a query language to the user with human readable but not
>> machine
>> readable semantics. Take an example from the HTTP 4 spec
>> http://www.w3.org/TR/html4/interact/forms.html
> 
> i always cringe when people refer to forms as query language. unless you
> have a form where you simply tunnel a query language ("enter your SQL
> query here and we'll trust you that you don't do anything stupid and will
> run it unsanitized against our database"), a form is a specific service
> that probably will be translated into a query somewhere, but the form
> itself is data model for a service-specific request. i guess my view of a
> query language is that of a generic language, and forms are the opposite
> of that.
> 
>> <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 .
>> }
> 
> these are entirely different things. one is the service surface, the other
> is one possible service implementation. the form might run against a SQL
> backend, or might run against a RDF backend and do all kind of data
> mapping and data cleanup voodoo to make sure you get quality results.

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.

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.

> 
> cheers,
> 
> dret.
> 

Social Web Architect
http://bblfish.net/


Received on Tuesday, 13 November 2012 09:38:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:33 UTC