GET and POST RDF with HTML forms

In Wraf [1], we will build a presentation system there the
presentation logic is stored in RDF.  This builds on a concept for the
session, that in turn builds on a query language.

I have recently discussed this with Stefan, and I have also reviewd
some earlier discussions on the subject from last year.


The goal is to find a way to create a web application for a knowledge
community:

        http://uxn.nu/wraf/RDF-Service/doc/html/hdc.html


A generic session is any type of communication between two agents.

But the focus here is the session that consists of people using web
browsers to communicate with the service through a HTML interface.

The session consists of information requests and information
presentation.  The 'user' will ask for specific information and many
times also give information.



The simplest way to request information is to just ask for a specific
resource, as with a normal URL.  The answer to the question depends on
the context.  The context will consist of HTTP request metadata and
the session.  The session will often hold the identity of the user and
the users preferences.  It tells the service to give the answer in
HTML form and to give an answer of 'medium length'.

We would like to use the semantics of http GET and POST.  GET is for
requesting information and POST is for submitting information.  The
PATH specifies the focus resource.  The QUERYSTRING part can be used
as a presentation modifier.

We are here looking for a way to ask question using HTTP.  Simple
question should just use the URL.  But what will more complex
questions look like?  Questions could maby look like:

  http://give.me/person/jonas_liljegren
  http://give.me/person/jonas_liljegren/intrests
  http://give.me/person/liljegren/intrest/RDF
  http://give.me/person/jonas/thoughts_about/RDF/related_to/AI
  http://give.me/AI/related_to/RDF/according_to/jonas
  http://give.me/liljegren_j.html
  http://give.me/persons?order_by=last_name
  http://give.me/liljegren_j?mode=edit

The URL is here just a type of query.  It has no relation to physical
storage of the information.  The actual information could even be
stored on another server.  But the server part says something about
the authority of the answer.

The point here is to let the service try to answer every GET request.
The URLs should be easy to remember.  Old URLs should work even after
reorganisations of the material.

The URL parser will mainly work by mapping path segments to resource
labels.  The focus resource is identified by the whole path.  If the
first segment is a predicate, the next segment is taken to be the
object of the resource property.  The remaining segments is parsed to
add more restrictions to the query.  If a segment is a class, the
resource will be of that type.  The following segment can be a
subclass of the class or another class.  The whole URL could also
match a known resource URL.

The request URL will create a new resource representing the answer to
the parsed question.  This resource could take the form of a DAML
class, defining the criterions for class membership.

The dot-extension will, if existing, be taken as the prefered response
format.  It could for example be html, xhtml, rdf or txt.  The
http ACCEPT metadata should also be used.

The presentation of the answer will be formatted according to the
number of matched resources, the specific criterions and the session
context.  With only one matching resource, it will probably be
displayed in whole.  With several matches, there will probably be a
list of answers.

If you ask for a person phone number, but the service finds two
persons with the same name, the service will have to ask for more
information about which person you are refering to.  If the
alternatives are few, this counterquestion is best put in the form of
a list of options.  For a larger amount of alternatives, a list of
classes could be presented, or you could just be asked to give more
specific criterions.  This makes up the steps of refining a query;
from list to item to subitem.



The POST part has been detaild in a previous posting.  It's basicly
about submitting new statements. The statements could be said to be
related to the URL if nothing else is explicitly specified.



HTML FORMS

Stefan proposed that the HTML form itself should be a resource that
gives metadata for all the fields.  Every time a form is to be filled
out, it gets a unique resourse, as an instance of the specific form
class.  Each field is a resource containing data about what is valid
data and how the field value will be inteprated.  Some values could
be translated to statements and other values could be used as
metainformation for the submitted data.  The fild names would be the
URIs for the resources.

The form data is stored as properties for the unique form resource.
This data is translated into new statements by some "parser" specified
by the metadata for the form class.  In most cases, the original raw
form data will soon expire into oblivion.


[1] http://www.uxn.nu/wraf/

-- 
/ Jonas Liljegren

The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/

Received on Monday, 12 March 2001 10:14:39 UTC