The SWAMP Architecture allows for various protocols to be used to convey knowledge. One class of protocols, general transport protocols, allow any RDF knowledge base to be conveyed (subject to issues of security, size, etc). Most other protocols are application-specific, allowing only a specific kind of information to be conveyed.
Many protocols, including HTTP, SMTP, TCP, and UDP, are design to allow general transport of information, but do not include a standard knowledge representation mechanism. These protocols can be used as part of a SWAMP transport protocol.
This document shows how to use these standard protocols as SWAMP transport protocols. In each case, the process involves specifying a way to identify the knowledge representation language and specifying what knowledge about the message is required for or provided by the protocol implementation.
The server address is an absolute URI.
In servicing an HTTP HEAD or GET request, the extra header "Conforms-to: http://www.w3.org/2002/03/swamp/transport-1" is added.
Messages can be sent with HEAD, GET, or POST. Messages sent with HEAD get only a status code back, and are declared to be non-committal. Message sent with GET are declared to be non-committal. Any kind of message may be sent with POST, although clients SHOULD use HEAD and GET when possible. The distinction is nicely explained in TimBL's Style Guide: User Input, and Yukka Korpela's GET and POST in HTML forms.
To send with HEAD or GET, any of several techniques may be used by clients and MUST be accepted by the server:
To send using POST, either:
Content-Encoding must be handled for POST. Maybe we should have SWAMP-Content-Encoding on the parameterized versions, to allow compression.
@@@ how does the metadata get presented?
Just send one or more RFC822-style headers, a blank line, then content. One header is used, the Content-Type header, as with HTTP. Any other headers, if present, get encoded into the message (somehow).
The experimental Trivial Object Description Language (TODL) 1.0 can be used to encode any RDF graph. Very simple. Joy joy.
Should we register this ASAP? Or something to not be an X?
See RFC 2046 and RFC 2048.
Good if you like XML.
kb1 = /* knowledge to send */ kb2 = /* knowledge to possibly use but not send */ recipient = /* RDF identifier for message recipient */ replykb = send_and_wait(kb1, recipient, kb2); or send_and_callback(kb1, recipient, kb2, callback_function); or send(kb1, recipient, kb2) (when you're not interesting in a reply, or even knowing if it got delivered.)
Servers could open the network listening ports themselves, or be run like CGI or from inetd when the connection has been made.
accept(&messkb, &metakb) where the metakb has info from the protocol stack about the message. It's more trustworthy, etc. OR metakb includes reified messkb. And it's just added to by accept. reply(returnMess, [message id]?)
$Id: general-transport.html,v 1.1 2002/03/29 20:02:53 sandro Exp $