- 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