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

Hi ,

For what it's worth, the form paradigm is exactly how API requests are 
processed and mapped to SPARQL queries in OpenPHACTS.
The API is an extension of the Linked Data API (LDA) [2] and Puelia-PHP [3].

An example request looks just like a URL generated via a GET form 
submission:

http://ops2.few.vu.nl/compound/pharmacology/pages?uri=http%3A%2F%2Fwww.conceptwiki.org%2Fconcept%2F38932552-111f-4a4e-a46a-4ed1d7bdf9d5&activity_type=Potency&minEx-activity_value=4&activity_unit=micromolar&_pageSize=5&_page=1&_orderBy=%3Factivity_value

The users are only required to provide a value for the 'uri' parameter 
while the rest are optional.

LDA has vocabulary that allows one to specify 'short names' for URIs, 
and in turn these short names can be used as names or values for GET 
parameters.

Each URL (excluding the GET vars) corresponds to a canned SPARQL query.

When the server receives a request, it will:
1. Strip prefixes up to '-'
2. Map parameter names to URIs.
3. If the URI occurs in the corresponding SPARQL as predicate, replace 
the object of that triple with the user supplied value.
4. Use a URI if the value is a delared 'short name', otherwise a Literal.
5. Prefixes min-, max-, minEx- and maxEx- cause an arithmetic FILTER to 
be applied to the object of the predicate with the operators '>=' , 
'<=', '>' and '<'.
6. Use the values of '_pageSize', '_page', and '_orderBy' to specify 
'LIMIT', 'OFFSET' and 'ORDER BY' clauses.

[1] specifies the result template for each call, giving a list of 
parameters that can be used (click to expand things).
[4] is the OpenPHACTS Explorer, a demo UI which basically provides users 
with forms to generate API requests and displays results.

In general this has so far been received very well both by the UI 
application developers and end-users.
I'd be happy to give a more detailed overview, if others believe it is 
relevant/interesting to the WG.

Cheers,
Antonis

[1] http://ops2.few.vu.nl/api-config
[2] http://code.google.com/p/linked-data-api/
[3] http://code.google.com/p/puelia-php/
[4] http://explorer.openphacts.org/

On 11/13/2012 11:47 PM, Wilde, Erik wrote:
> hello henry.
>
> i'll refrain from further emails after this one unless others think this
> conversation is useful.
>
>> Let us get back on the topic of pagination. The following html form would
>> do
>> as a simple pagination form for a collection <> .
>> <FORM action="p?" method="post">
>> <P>
>> page number:  <INPUT type="text" name="page"><BR>
>> entries per page: <INPUT type="text" name="pageSz"><BR>
>> <BUTTON name="Get answers" value="submit" type="submit"></BUTTON>
>> </FORM>
>> Are you with me here?
> this is the service surface and if you used standardized link relations,
> no form is required an RFC5005 would happily guide all interactions. let's
> assume you don't want this. if your service documented what the field
> names mean, then this would be a proper service.
>
>> So let's transform the above form into a SPARQL query
>> SELECT ?page ?pageSz
>> TO <p>
>> WHERE {
>>   [] a PaginationSlice;
>>      :pageNumber ?page;
>>      :entriesPerPage ?pageSz .
>> }
> you cannot "transform a form into a SPARQL query." a form is a template
> that defines what kind of input a service expects. clients are expected to
> fill out the template, taking into account all constraints that are
> defined as part of the service. servers validate the data, and if the
> request validates the pre-conditions, it is executed. this can mean that
> (part of the) form data is used to populate a query. it can also drive
> code that has no query component to it whatsoever, and simply computes the
> service's response.
>
>>>> 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?
>> Later when we have worked out the details we can get the RDFa people to
>> work out
>> some how to markup a real form neatly and beautifully so that the html
>> form and the
>> query can be nicely merged together... For the moment I am just
>> describing the
>> general idea. We can leave UI for later, when the model is clear, and
>> work with
>> psychologists to find out what people find most natural.
> personally speaking, for the immediate WG goals, there's too much "and
> yes, we need to fill in all those blank spots" in here. all i have been
> trying to do is explaining how REST approaches this problem, and how
> existing standards could be used to prevent us from reinventing some
> wheels.
>
>>>> 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.
>> Because a form is just a query to the user!
> a form is a template with a service-defined model. a query languages
> queries any kind of data that's managed based on some general-purpose
> metamodel. these are different things. you might have visions of how forms
> and/or query languages could be changed or designed to completely change
> how things are currently working, but going back to ISSUE-33, the question
> was how to expose pagination affordances in a more general way, and web
> architecture and existing standards give us a pretty solid starting point.
>
> cheers,
>
> dret.
>
>

Received on Thursday, 15 November 2012 09:59:46 UTC