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: Mon, 12 Nov 2012 22:33:35 +0100
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>
To: "Wilde, Erik" <Erik.Wilde@emc.com>

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

<FORM action="http://somesite.com/prog/adduser" 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 
   <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.


> cheers,
> dret.

Social Web Architect

Received on Monday, 12 November 2012 21:34:07 UTC

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