- From: Henry Story <henry.story@bblfish.net>
- Date: Mon, 12 Nov 2012 22:33:35 +0100
- To: "Wilde, Erik" <Erik.Wilde@emc.com>
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>
- Message-Id: <DB49335E-0ADB-4C62-9A19-50034B96FEB6@bblfish.net>
On 12 Nov 2012, at 19:57, "Wilde, Erik" <Erik.Wilde@emc.com> wrote: > hello henry. > > On 2012-11-12 9:40 , "Henry Story" <henry.story@bblfish.net> wrote: >> The other way I think one could do this is with something like an RDF >> form. >> Thinks of every page as containing a form. >> Think of the form as a query to the user. >> Give it semantics: then you can think of a form as a SPARQL query to the >> user. >> That query could be something like "which slice X of the answer do you >> want?" >> then the robot/human can know the vocabulary of the query asked of it, and >> can answer by POSTing to the collection. > > maybe i am pointing out the obvious here, but a URI template is an > essential part of a form (when wrapped in a media type that describes > parameters so that clients can instantiate URIs at runtime). It is part of a GET form, not of a POST form. > 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 <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 . } The advantage of this second way of writing things, is that robots could clearly understand the form. > separating the service surface (here is what you can ask > this service) from the service implementation (here is the query this > request is translated to) usually is a good idea. yes, that is the advantage of thinking of this semantically. Just think of the usual "multipart/form-data" return types as just another syntax for sending back SPARQL answers. What I am advocating here is that the form be enhanced with semantics. If you do that then you get pagination for free. Henry > > cheers, > > dret. > Social Web Architect http://bblfish.net/
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 12 November 2012 21:34:07 UTC